LLMs are the primary daily tool in the stack

The belief

LLMs top the daily-use stack by frequency. Not as an extension of self: as the tool you open first. Code, writing, data analysis, learning, structured thinking - LLMs handle the first pass on all of it. That is a factual usage observation, not a philosophical claim.

The specific substrate is interchangeable. When the primary goes down, you pull up a local fallback. Continuous LLM access is non-negotiable; the vendor is not.

How to apply

1. Default to LLM-first on any first-pass task. Code review, draft writing, data pattern identification, concept explanation - start with the LLM before reaching for a specialist tool or doing it manually. Specialist tools enter when the LLM output has a specific gap, not before.
2. Configure a multi-substrate stack, not a single-vendor dependency. Maintain at least one cloud primary and one local fallback (ollama or equivalent). When primary access drops, the fallback is already warm. Which provider delivers is a logistics question.
3. Build per-domain wrappers for recurring workflows. A general-purpose session is high-friction for specialized work. Create persistent context per domain: a data analytics helper, a writing helper, a PRD summarizer. Structure each around the domain's curriculum or spec. "This has replaced my podcast addiction with a more interactive version."
4. Treat the LLM as build partner, not search engine. When building, the LLM drives code generation, not just lookup. "AI building AI is now." The shift from lookup-tool to build-partner changes how much context quality matters - which is why the second-brain exists.
5. Audit daily-use patterns to find where the LLM is absent. Any workflow answered by "no, I did it manually" is a candidate for a wrapper. The goal is not LLM for everything; it is to have a deliberate reason when you do not use it.

What this is not

• Not a claim that LLMs are always right. The belief is about daily-use frequency and first-pass default, not reliability or accuracy. Verification and judgment still sit with the practitioner. The LLM is the fast draft; the human is the editor.
• Not an argument for LLM-only workflows. Specialist tools - version control, structured databases, design software - stay where they are purpose-fit. LLM-first means the LLM enters before you reach for the next tool, not that the next tool disappears.
• Not mysticism about AI as an extension of self. This belief makes a frequency claim. It does not argue that LLMs think like you or that you think with them in some merged sense. That framing is imprecise and not load-bearing here.

Argues against

• "LLMs are a useful supplement, but core work should be done without them to maintain independent skill."
• "Vendor dependency risk means you should keep LLM use minimal and deliberate, not daily-primary."
• "Heavy LLM use signals low skill floor - practitioners who know their craft do not need the first-pass assist."

Where to go from here

If you want the positional form of this belief - why AI fluency is now a non-negotiable for PMs, not an optional skill - go to AI PM skillset table stakes. That belief sets the requirement; this one describes what meeting it actually looks like day to day.

If you want to understand why daily LLM use at this volume requires a persistent context layer, go to second brain is context layer. The second-brain exists because LLM-as-primary-daily-tool created a context management problem worth solving.

If you want the parent theme with the full evidence arc and the AI PM skill inventory, go to the AI PM skillset theme.