Marq AI Wiki

AI-Native Litmus Test

3 min read

The AI-Native Litmus Test

When you need an answer or an output, do you reach for a system you built, or do you interrupt a person, schedule a meeting, or do it by hand?

If the work has been turned into architecture, the system answers. If it still lives in someone’s head, you are still the human plugin. This is the practical test for AI native.

The principle

The test is not “do you use AI.” It is whether the knowledge and judgment required to produce something has been encoded into a system that can produce it on demand, by anyone, without interrupting the person who holds it in their head. Being busy with AI is activity. Replacing a recurring human bottleneck with a system is fluency.

A quick way to apply it to any task: ask “could a command answer this instead of a conversation?” If yes, and you built it, you are AI-native for that task. If no, that task is a candidate for your next workflow.

Signals

Beyond the single question, these are the behaviors that distinguish someone who is AI-native from someone who simply has access. Read them as a self-assessment.

  • You manage AI like a capable but inexperienced collaborator, not a tool you operate.
  • You decompose work, deciding what to hand to AI and what to keep, and you know where AI tends to fail for your specific work.
  • You assemble the right context before you prompt, instead of dumping in everything or providing almost nothing.
  • You treat the first output as a draft and refine it to done, rather than accepting it as-is or abandoning the effort.
  • You package repeatable work into a reusable system (a command, skill, or workflow) instead of redoing it by hand each time.
  • You spend more time planning and improving the system than doing the task itself, so each run gets better than the last.
  • Your environment is agent-native: anything you can do, your AI can do the same way.
  • You make tacit knowledge explicit, encoding goals and judgment into the system so the work no longer depends on “you just know.”

Examples

Status of a contractor’s work

  • Before: message them, or set up a recurring check-in to find out where things stand.
  • After: the state is built into the project itself (per-workflow trackers and specs). A single command reads it on demand and returns a glanceable status table of every workflow. The recurring meeting was replaced by a system anyone can run.

Patterns to capture

A running backlog of work that should pass the test but does not yet. When one of these gets turned into a command, skill, or workflow, promote it into Examples above as a Before/After.

  • A recurring meeting whose only purpose is a status update.
  • A report you assemble by hand from the same few sources every week.
  • A question only one specific person can answer.
  • Onboarding knowledge that lives in a single veteran’s head.
  • A decision that stalls because the context is scattered across tools.

Sources

Graph View

Backlinks