Blog

Seneca had a rule about correspondence: don’t respond to letters the moment they arrive. Set them aside. Let the thought settle. Respond when you have something worth saying rather than when social pressure demands a reply.

That’s not how we use AI.

We’ve built real-time AI into everything — always-on assistants, instant analysis, immediate responses to any question. The design assumption is that faster is better, that removing latency from every cognitive task creates value. But there’s a cost to always-on AI that’s rarely discussed: it can quietly erode the capacity for sustained, independent thinking that makes good product decisions possible.

The Real-Time AI Trap

Here’s a pattern I’ve noticed in my own work, and in teams I consult with: AI availability changes the character of thinking, not just the speed. When you know an instant answer is available, the instinct to work through a problem yourself diminishes. Not dramatically — just enough to matter.

I caught myself asking Claude to “think through the pros and cons” of a product prioritization decision I’d made dozens of times before. I wasn’t seeking new perspective. I wasn’t dealing with an unusual edge case. I was just avoiding the mild friction of working through it myself, because the alternative (ask AI, get immediate answer) was so frictionless.

That’s a problem. Not because AI analysis is bad, but because the ability to reason through prioritization decisions independently is a core PM competency — and like any competency, it atrophies without use. Offloading the thinking doesn’t just remove the task; it removes the practice.

Offloading vs. Outsourcing: The Line That Matters

There’s a useful distinction worth making explicit:

Offloading is using AI to handle tasks that don’t require your specific judgment — summarizing a 50-page research report, extracting action items from meeting transcripts, generating first-draft language for a spec. The value is real and the cost is low. You’re not losing anything by having AI do these tasks. You free up cognitive bandwidth for higher-leverage work.

Outsourcing is using AI to handle the judgment calls that should be yours — deciding which problems to prioritize, evaluating strategic trade-offs, determining what your users actually need vs. what they’re asking for. The immediate output looks similar, but the long-term cost is real: you’re not building the judgment muscle that makes you better over time. You’re borrowing it from a model that has no stake in your actual outcomes.

The line between the two is often subtle and context-dependent. Summarizing research is usually offloading. Asking AI to “tell me what to focus on this quarter” is usually outsourcing. “Help me stress-test the prioritization I’ve already done” is offloading. “What should we build next?” is outsourcing.

A Batched Approach to AI That Preserves Judgment

The batching principle is the practical application of Seneca’s rule. Instead of treating AI as a real-time response system for every cognitive task, structure AI interaction into deliberate sessions with protected thinking time in between.

Here’s the workflow I’ve been running for eight months:

Morning AI session: Feed the system previous day’s metrics, key questions I’m working on, and documents requiring analysis. Let it run. Close the interface. Don’t interact with AI analysis until I’ve done my own initial thinking on the same questions.

Midday synthesis: Review AI output alongside my own thinking. The AI analysis is one data point — sometimes it changes my view, sometimes it confirms it, sometimes it raises considerations I missed. The key: I’ve already done the first-pass reasoning before seeing what the AI produced.

Protected thinking blocks: Two 45-minute windows per day with AI interfaces closed. This is where strategy work happens — the kind of slow, uncomfortable reasoning about difficult trade-offs that can’t be outsourced without losing the benefit of doing it.

The counterintuitive result: I use AI more effectively when I use it less constantly. The batching creates space for my analysis to develop before AI analysis augments it, which produces better final outputs than feeding every question to AI the moment it arises.

The Organizational Design Implication

If you’re leading a product team, the real-time AI trap isn’t just a personal productivity issue — it’s an organizational one. Teams that use AI to substitute for strategic thinking will develop weaker strategic thinking over time. The meetings get faster. The decisions get more confident. And the quality of the underlying reasoning quietly declines.

The antidote is building deliberate judgment-development practices into team rhythms: requiring people to bring their own analysis before AI analysis is introduced, creating space for debate and disagreement that doesn’t get short-circuited by “the AI says,” and treating the quality of reasoning — not just the quality of outputs — as something worth protecting.

As Kahneman’s research shows, fast thinking is efficient but prone to systematic error. The AI automation paradox is that AI often makes fast thinking faster without making it more accurate — which is exactly the problem Seneca was trying to solve with his correspondence rule two thousand years ago.

Your Turn: Apply This Today

The cost of real-time AI is often invisible until it shows up in your team’s burnout or your product’s churn rate. Here’s how to surface and manage it:

• Audit your AI features for “always-on” demands. List every AI feature in your product that creates an expectation of real-time response — from users or from your systems. For each one, ask: is this expectation necessary for value, or just for perceived responsiveness?
• Calculate the true infrastructure cost of real-time AI. Pull the cost data on your most-used AI features. Break it down by: inference cost, latency infrastructure, on-call engineering support, and incident response. Present the full number to leadership alongside the user value. That’s the honest trade-off.
• Segment your users by latency sensitivity. Not all users need real-time AI. Survey or instrument your user base to understand who notices — and cares about — latency vs. who just wants accuracy. Design tiered AI experiences that match investment to actual user need.
• Introduce “async AI modes” for non-time-critical workflows. Identify user workflows where a 5-minute or 1-hour delay is completely acceptable. Move those workflows to async processing. Invest the cost savings in making real-time AI faster where it actually matters.
• Set a “response time contract” with your users. Be explicit in your UI about when AI outputs are real-time vs. batch-processed. Users who know when to expect results are more patient than users who feel they’re waiting unnecessarily.
• Apply Seneca’s discipline to your roadmap. Before adding any new real-time AI feature, ask: is this urgent for the user, or just urgent-feeling? If the value doesn’t require immediacy, design for async first and real-time only when the user’s workflow demands it.

The batching approach also helps with the problem Kahneman’s framework identifies: when you don’t interact with AI constantly, you can engage System 2 evaluation at the right moments rather than burning cognitive load on continuous vigilance.

Building AI into your product team’s workflow and watching independent judgment quietly erode? I consult with product organizations on AI work design, decision quality, and preserving the judgment capacity that makes AI actually useful rather than just fast. Let’s talk.

Kahneman’s dual-process theory splits human cognition into System 1 (fast, automatic, intuitive) and System 2 (slow, deliberate, analytical). System 1 handles routine pattern-matching instantly. System 2 engages for novel problems requiring conscious reasoning. The trouble is that System 2 is expensive — it’s slow, effortful, and tires easily. Humans naturally try to minimize how much they use it.

Here’s what Kahneman didn’t fully anticipate when he published Thinking, Fast and Slow in 2011: what happens when AI automates the System 1 tasks but simultaneously requires System 2 oversight of everything it does.

That’s the AI automation paradox. And it’s creating a cognitive load problem that most product teams haven’t fully reckoned with.

Why AI Automation Increases Cognitive Load Instead of Reducing It

When I started running a 20-agent AI system, I expected it to free up cognitive bandwidth. It did — for the tasks the agents handled correctly. What I didn’t account for was the continuous System 2 vigilance required to monitor outputs I could no longer trust automatically.

My email triage agent sorts and prioritizes correctly about 90% of the time. That sounds high. But 10% errors across 200 emails a day means 20 potentially misrouted messages — enough to create real problems. So instead of spending System 1 attention on scanning email (which I was good at), I now spend System 2 attention verifying the agent’s categorizations. That’s cognitively harder, not easier.

This matches what Ethan Mollick documented in his research on human-AI collaboration: AI creates “jagged frontiers” where performance is excellent in some areas and surprisingly poor in adjacent ones, with no obvious pattern. Users can’t develop the intuitive trust that would allow System 1 to handle AI oversight. Every interaction requires deliberate evaluation.

The result: permanent System 2 vigilance for tasks that AI is supposedly handling for you.

The Design Implications for AI Products

Understanding the Kahneman paradox should change how you design AI features — both for your users and for your own team’s workflows.

Narrow scope reduces oversight burden. The AI tools I trust most handle a single, well-defined task with transparent reasoning. My meeting transcript parser does one thing: it extracts action items and shows its reasoning for each one. The narrow scope makes verification fast. The broad-scope tools that promise to “handle everything” create the most cognitive load because you can never develop calibrated trust — each output requires full evaluation.

Confidence signaling is a product feature, not a nice-to-have. Tools that flag their own uncertainty let users shift appropriately between System 1 and System 2. When an output is flagged as low-confidence, the user engages deliberate evaluation. When it’s flagged as high-confidence, they can trust it more readily. This isn’t just better UX — it’s cognitively more honest about what AI actually does. Most AI tools present every output with equal confidence, which forces users into constant System 2 vigilance as the safe default.

Failure mode design matters more than accuracy optimization. The most dangerous AI failure is not “wrong with high confidence” on a flagged edge case — it’s “wrong with high confidence on something that looks routine.” Design your AI features to fail obviously, not silently. When the agent can’t handle something well, it should say so explicitly rather than producing a plausible-sounding but incorrect output. Graceful, visible degradation builds appropriate trust calibration over time.

When to Let System 1 Take Over

The goal isn’t permanent System 2 vigilance — that’s unsustainable and defeats the productivity case for AI. The goal is building the pattern recognition that allows appropriate trust to develop over time.

This happens naturally when the AI operates in a narrow enough domain, with enough transparency, for long enough that users can develop accurate intuitions about where it succeeds and where it fails. That’s the design objective: not “AI handles everything” but “users develop calibrated trust in specific AI behaviors” — which takes time, transparency, and intentional scope management on your part as a product builder.

Nielsen Norman Group’s research on AI mental models points in the same direction: users who develop accurate mental models of AI capabilities use AI tools more effectively and report higher satisfaction than those operating with either over-trust or under-trust. Your product design should actively support accurate mental model formation, not just maximize apparent capability.

If you’re thinking about how this connects to team productivity, the Kahneman paradox is part of why AI makes knowledge workers more productive but not always more effective — the cognitive overhead of AI oversight is a real cost that productivity metrics rarely capture.

Your Turn: Apply This Today

The cognitive load paradox is subtle but consequential. Here’s how to design around it:

• Audit your AI features for “trust calibration.” For each AI output your product surfaces, ask: does the UI communicate how confident the AI is, and what the cost of being wrong is? Presenting uncertain outputs with the same visual weight as certain ones trains users to overtrust.
• Design “friction with purpose” into high-stakes AI decisions. Where an AI recommendation could lead to a significant downstream consequence, add a confirmation step — not to slow users down, but to activate System 2 thinking. The pause is the feature.
• Track “AI override rates” as a product health metric. Measure how often users accept AI suggestions without modification vs. how often they edit or reject them. If the override rate is near zero, users may be overtrusting outputs that don’t deserve it.
• Run a “cognitive load audit” on your highest-traffic AI workflow. Map every decision a user makes in the flow. For each one, ask: is the AI reducing cognitive load in a way that helps, or in a way that just defers the thinking to a less capable moment?
• Test your AI features with novice and expert users separately. The cognitive load paradox hits differently across experience levels. Experts are more likely to catch AI errors; novices are more likely to overtrust. Design different trust signals for different user segments.
• Build an “error recovery” path for every AI recommendation. Design the product so that when an AI suggestion turns out to be wrong, the user can recover without significant cost. If the cost of recovery is high, you must add more human checkpoints before the decision commits.

Building AI features and seeing that users aren’t developing the trust and adoption you expected? I consult with product teams on AI UX design, cognitive load, and building the right trust architecture for AI-powered products. Let’s talk.

Sam Altman’s “Universal Basic Compute” proposal — providing every person direct access to computing power rather than just AI-generated outputs — is one of the more interesting ideas circulating in AI policy circles right now. The concept: instead of waiting for AI productivity gains to trickle down through labor markets, give people direct stakes in the compute layer itself. Think universal healthcare, but for GPUs.

Whether or not Altman’s specific proposal gains traction, the question it raises is worth sitting with for anyone building AI products: When compute becomes democratized, what actually determines who wins?

The Access Fallacy in AI Product Strategy

A lot of product strategy right now is implicitly built on access as the moat. We have access to GPT-4, or Claude, or Gemini — and our competitors don’t, or can’t afford it, or don’t know how to integrate it yet. The access gap creates a temporary competitive advantage.

But access moats in software have a historical tendency to close faster than anyone expects. AWS made infrastructure a commodity. Stripe made payments a commodity. Shopify made e-commerce infrastructure a commodity. In each case, the teams that built durable advantages weren’t the ones who had early access to infrastructure — they were the ones who had deep understanding of the customers that infrastructure served.

AI access is on the same trajectory. When compute democratizes — and it will, whether through Altman’s UBC proposal or through market price compression or through open-source model proliferation — the teams with genuine customer depth will compound. The teams whose strategy was primarily “we have AI and they don’t” will find themselves competing on a level playing field with no differentiation.

What Actually Differentiates When Access Is Universal

I’ve been thinking about this through the lens of what I’ve observed building digital products for ministry and faith-based audiences across multiple continents. The access gap closed faster than expected in those markets — within 18 months of us integrating AI capabilities, smaller competitors had comparable features. The products that retained users weren’t the ones that had AI first. They were the ones that had the best data on their specific users, the deepest understanding of context, and the most nuanced sense of what “correct” actually means for their audience.

Universal compute access amplifies this dynamic. When everyone can fine-tune models on their domain data, the differentiator isn’t who has AI — it’s who has:

• Better training data. Your proprietary understanding of user behavior, domain-specific language, and edge cases that general models handle poorly.
• Deeper contextual judgment. The ability to know when the AI output is 95% right but contextually wrong in the 5% that matters most for your specific users.
• Domain expertise that AI can’t replicate without you. The tacit knowledge of what “good” looks like for your users that only comes from years of serving them closely.

This is essentially the sovereignty question applied at the product level: the teams with data sovereignty and domain sovereignty will outperform those with only infrastructure access.

The Distribution Problem That Persists

Altman’s proposal also highlights something product teams building global products need to think about more carefully: democratized access doesn’t automatically produce democratized value.

When we expanded our platform to serve users in the Global South — smaller congregations, rural communities, under-resourced organizations — equal access to the same AI features didn’t produce equal outcomes. The features were calibrated on majority-culture usage data. The AI’s judgment about what was “helpful” reflected a particular cultural context. The teams with equal access to the technology were not equally served by it.

Real democratization isn’t just access to compute. It’s access to compute that reflects your context, your language, your use cases, and your community’s understanding of what good looks like. That gap doesn’t close by lowering the price of GPUs. It closes through deliberate investment in representative data and culturally-aware product design — which is an organizational commitment, not an infrastructure problem.

What This Means for Your Roadmap Now

If your AI product strategy relies primarily on access advantages, now is the right time to audit what else you’re building. The questions worth asking:

• What proprietary data do you have that makes your AI outputs genuinely better for your specific users than a competitor using the same foundation model?
• What domain knowledge is baked into your product design that a new entrant with equal AI access couldn’t replicate quickly?
• Are you building the customer relationships and feedback loops that compound into better AI outputs over time?
• If your AI access became equally available to your top three competitors tomorrow, what would still differentiate you?

The teams thinking through those questions now will be better positioned when the access gap closes — and it will close. The question is whether your strategy is built on a foundation that gets stronger when it does, or one that becomes irrelevant.

This connects to the deeper question of what your product is actually for — because access democratization also changes who your product is obligated to serve well, not just who it can technically reach.

Your Turn: Apply This Today

If AI is table stakes, your differentiation must come from somewhere else. Here’s how to find it:

• Inventory your non-AI moats. List every source of competitive advantage your product has that has nothing to do with AI — network effects, proprietary data, community, brand trust, distribution, switching costs. If the list is short, that’s your strategy problem to solve.
• Run a “when AI does it for free” scenario. Identify the three AI features you’re most proud of. Then ask: if OpenAI, Google, or Microsoft offered the same capability for free tomorrow, what would remain of your value proposition? Build toward that remainder.
• Find the “contextual advantage” in your market. What does your product know about your specific user context — their industry, their past behavior, their workflow — that a general AI cannot know without being told? Build features that leverage that context depth.
• Invest in trust infrastructure, not just feature infrastructure. As AI becomes ubiquitous, users will choose products they trust to handle their data, protect their privacy, and behave consistently. Document and communicate your AI governance practices. Trust is a differentiator.
• Map the “last mile” problem in your category. AI handles the generic parts of most workflows. What’s the last 20% that requires human judgment, contextual knowledge, or professional accountability? Design your product to excel in that space, not compete in the generic space where AI wins on cost.
• Define your “AI commodity” timeline. Make a bet: in 18 months, which of your current AI features will be commoditized? Work backward from that bet to decide what to build now that has staying power beyond the commoditization wave.

Building AI products and thinking through what differentiates you as the access moat closes? I consult with product leaders on AI product strategy, data differentiation, and building durable competitive advantages in AI-native markets. Let’s talk.