AI or Nah? Why “where should we use AI?” is usually the wrong starting point

This piece is a shortened, written adaptation of “AI or Nah?”, a talk I gave at the 2026 VIA Summit.

Making sense of AI whiplash

You've probably heard some version of these claims: “My firm is AI-native.” “AI won't take your job, but someone using AI will.” “Connect AI to all your firm's information to get maximum leverage.” Then, in the next breath, you're warned that an agent could delete your files or expose sensitive data or, worse yet, destroy humanity.

Knowledge workers are being told to move faster with AI or get left behind. In venture operations, we're often the ones being tasked with or taking on AI automation. We work with a lot of sensitive information, which makes the instructions feel contradictory: give AI more context, but don't expose data. Build agents, but don't let them make mistakes. Check every output, but still deliver the promised time savings. Weirdly, there's even pressure to make sure no one can tell you're using AI.

The frustrating part isn't just the noise. It's that none of those claims or concerns tell us how to make a good decision about the work in front of us. There isn't one correct way to use AI across every task or organization.

"Where should we use AI?" is the wrong question. It skips straight to a tool before understanding anything about your operating context. Before you ask whether you should use AI, there is a long series of questions to consider, including whether the underlying problem is worth solving and what exactly makes the process frustrating.

AI is the last question. First ask what the work requires. Then decide whether AI, automation, software, a person, or no intervention at all is the simplest answer. Below, I share a three-stage framework that puts the diagnosis first.

Test before you trust

In the pre-session survey for the talk, roughly a third of respondents identified as AI skeptics, a third as optimists, and a third as overwhelmed. (No one identified as AI-pilled.) Those are different starting points, but they lead to the same responsibility: understand the technology well enough to form your own judgment.

It sometimes helps me to substitute “mobile,” “software,” or “the internet” for “AI.” If a technology might reshape our work, we should learn enough about it to recognize where it's useful, where it creates new work, and where it doesn't belong. That applies even if we're skeptical. It doesn't mean putting AI everywhere, and it doesn't mean experimenting with sensitive information without appropriate boundaries.

I've always learned technology by playing with it and seeing how far it can go. This has ranged from finding snippets of code scattered across the internet that would make glitter fall from the cursor when I was a teenager with a blog, all the way through vibe coding personal software in Claude Code. Like putting together IKEA furniture, it doesn't always work on the first try. Sometimes it takes many attempts to get something useful. A disappointing first prompt isn't necessarily a verdict on the technology, just as a polished first demo isn't proof that a workflow is ready to deploy.

My expectation is that these tools will become easier to use and more reliable over time. But the useful habit now is getting comfortable with iteration: try something bounded, inspect the result, adjust, and learn what you can and cannot trust AI for today. The answers will keep changing as both the tools and our understanding improve.

The venture operator's edge

I believe VC operators have a distinctive vantage point and role to play in this technology transition. We watch our firms evaluate companies promising to reshape technology, and then often become the people responsible for seeing whether those promises survive contact with tactical work and real consequences.

That perspective matters in financial and regulated environments. We see the tradeoffs, understand the exceptions, and conduct work that requires high precision and speed. We can help distinguish what technology could do today from what the organization is prepared to use responsibly.

I've benefited enormously from the leverage AI can create. But the more I use it, the more I find myself replacing “What can AI do?” with “What does this work require?” After a couple of years and countless experiments, I've started to organize that decision into three moves: prioritize, diagnose, and design.

The framework at a glance

Stage	Question it answers	Output
1. Prioritize	Is this worth solving at all?	Go / no-go
2. Diagnose	What's actually in the way?	A named obstruction
3. Design	What's the simplest fix?	A specific intervention

Stage 1: Prioritize

With most technology investments, we expect a business case. With AI, it can feel as if we're encouraged to throw it everywhere, see what sticks, and call usage a win. Experimentation is useful for learning, but deploying a workflow still needs a reason beyond the appeal of building a shiny new tool.

Before debating tools, size the problem. Six questions do that:

• Frequency: how often does this happen?
• Time burden: how much total time does it consume?
• Consequence: what happens when it's slow, wrong, or neglected?
• Friction: how much do people resist or avoid doing it?
• Value unlocked: what higher-value work would solving it free up?
• Maintenance cost: will the fix eventually cost more than the problem does?

A five-minute task can still be expensive if fifty people do it every week. Something can be extremely annoying and still fail this test: plenty of workflows are fine to leave alone because there is higher-value work you should be doing instead. Sometimes, though, I’ll spend an evening building a fix for an annoying task just because I’m curious or it sounds fun. In those cases, the learning or enjoyment is the point.

Stage 2: Diagnose

Two workflows can feel equally slow for completely different reasons, and the reason determines the fix. These five categories cover most cases:

• Judgment: nobody has decided what "correct" looks like; the answer depends on experience that hasn't been written down.
• Process: the rules exist but are inconsistent: different people follow different steps, or no one owns the outcome.
• Information: the facts exist but are scattered, contradictory, or hard to verify.
• Execution: everyone agrees what should happen, but doing it requires the same tedious steps repeatedly that nobody wants to do.
• Adoption: the system works, but only if a group of busy people reliably changes their behavior.

Most workflows are more than one of these at once. The useful move is asking which obstacle has to be resolved first. Alongside this: a readiness check. Are the inputs clear, the rules stable, and the desired output actually known? If the work isn't legible to the people currently doing it, it won't become reliable just because AI sits on top of it.

Capability is not readiness. A model may be able to do the task while the organization is still unprepared to use it reliably. Connecting AI to email, Dropbox, a CRM, and spreadsheets doesn't resolve stale records or conflicting versions. Someone has to define the sources of truth, reconcile critical information, and keep it current. That matters especially when the output feeds financial reporting, audits, or investor communications.

Readiness also means ownership: who is accountable for the output, who handles exceptions, and who maintains the workflow six months from now? What happens if this person leaves the organization? A good demo, a new agent, or a better model shows what's possible. It doesn't answer those implementation questions for us.

There's also a verification trap: a response built from the wrong business records can sound completely plausible. When information is contextual or partly subjective, a human reviewer may not immediately notice that the source was stale, incomplete, or attached to the wrong entity. A convincing answer isn't evidence that the underlying information is correct.

My approach is crawl, walk, run. Make the critical information and process legible to people first, then build on that foundation. A firm can't get the maximum benefit from AI while skipping the work of defining and maintaining its sources of truth. Once AI is crawling across our systems, that work matters even more.

Stage 3: Design

Once the obstruction has a name, the options widen past "AI or nothing":

• Stop doing it: eliminate work that no longer needs to happen.
• Continue manually: sometimes the manual cost is lower than the cost of building and maintaining a system.
• Redesign the process: fix the broken steps, inconsistent rules, or missing owner.
• Delegate or hire: sometimes judgment, trust, or a relationship is the actual point.
• Buy existing software someone else already built and maintains.
• Automate with deterministic rules, when inputs and outputs are stable and repeatable.
• Augment a person with AI, when the work involves language, interpretation, or synthesizing messy context.

Before choosing, ask what happens if the system is wrong. How costly is an incorrect result? What information is sensitive? Can the action be reversed? What needs human review? Decide explicitly what judgment should remain human, and who owns the final outcome.

The rule of thumb that falls out of this: automate stable work; augment ambiguous work. Clear inputs and a predictable output call for something that does the same thing every time. Judgment or synthesis calls for AI helping a person decide faster, not replacing the decision.

There's another distinction worth making: using AI to build a solution is not the same as using AI to run it. AI can help a nontechnical operator write a script, connect systems, and create a workflow that then runs on ordinary code. Sometimes AI's role is to help you build the solution, not to be part of it every time it runs. That still requires testing the code, checking the mappings, and assigning someone to maintain it.

Build AI capabilities, not just a list of use cases

The AI toolbox is broad, and your ability to use it can compound over time. When I started, I primarily used AI for writing. Then I began building agents on workflow platforms. From there, I moved into administrative work with Claude Chat and Cowork, and now I'm learning to build custom apps with Claude Code.

Each step changed what I could imagine doing next. That's why I don't think of AI only as a fixed list of use cases. Learning how to work with it can expand the range of problems you're capable of solving.

So “AI is the last question” isn't a reason to stop experimenting. It's a way to keep experiments grounded while you continue developing your capabilities. You can explore broadly and still be selective about what becomes part of a live workflow.

Keep comparing notes

The talk was designed as equal parts presentation and discussion. Despite AI technology being around for several years, we're still in the early innings of understanding how our work will be transformed. There is so much value in comparing notes with peers to understand what people are doing, where they're finding leverage, and what hasn't worked.

For the past year and a half, I've also hosted monthly AI for investors sessions where we compare notes and demo what we're building, step by step. That exchange matters because no one sees the whole picture from their own experiments alone. If you'd like to see live demos and have these kinds of conversations, I encourage you to sign up for these sessions here.