Most AI practitioners are further back on the competence curve than they think. Frequency of use tells you almost nothing. What actually separates levels is contextual judgment — knowing what the model needs, what it can't know on its own, and who's responsible for the gap. This post maps four observable orientations and what moving between them actually requires.
Most people who work with AI professionally have no idea where they actually sit on the competence curve. Not a criticism — just something you notice when you've watched enough practitioners work through the same class of problems.
A Pattern We Keep Noticing
There's a particular conversation we've had more times than we can count. Someone joins the Mesh network — a senior analyst at a mid-sized consultancy, or a product lead at a scaling SaaS company — and they describe their AI work with a quiet confidence that starts to slip under questioning. They use the tools. They've shipped things. They know the vocabulary. But when we dig into how they think about AI problems, something's missing. Not intelligence. Not effort. Something structural.
The inverse also happens, and it's equally instructive. A junior researcher at a think tank, someone who'd probably describe themselves as "still figuring it out," turns out to be operating with a level of contextual sophistication that most mid-career practitioners haven't developed. They can't always explain why their outputs are better. But they are.
This is the core tension in AI practitioner development right now, and we think it doesn't get discussed honestly enough. The field rewards people who sound advanced. It's less good at surfacing who actually is.
The Problem With How We Talk About AI Skill
The dominant framework most practitioners work from — implicitly, since almost nobody writes it down — goes something like: beginner uses AI occasionally, intermediate uses it frequently, advanced uses it for complex tasks. This is almost entirely useless as a developmental map.
Frequency of use tells you almost nothing. A marketing coordinator who writes fifty prompts a day for social captions and a machine learning engineer who writes three carefully constructed prompts for a research synthesis task are not on the same ladder, measured from the same rung. They're on different ladders entirely.
What actually separates practitioners at different levels isn't usage volume or even technical sophistication in isolation. It's something we'd describe as contextual judgment — the ability to understand what the model needs to know, what it cannot know on its own, and how the gap between those two things should shape everything from your initial framing to how you evaluate the output.
We'd go further: we think most AI training programmes, including some expensive ones, are optimising for the wrong signal entirely. They teach prompt syntax when they should be teaching epistemic habits.
The Part Nobody Demos: Context vs. Syntax
Here's what this looks like in concrete terms. Two practitioners, same task: summarise a set of customer support tickets and identify systemic issues.
Task-first approach** — adjusts by feel:
# Prompt written by a task-first practitioner
prompt = """
Summarise these customer support tickets and identify the main issues.
Tickets:
{tickets}
"""
Output is decent. Patterns get named. But the framing is generic — the model has no idea what "systemic issues" means in this business context, what the threshold for "main" is, or whether the goal is root cause analysis or triage prioritisation.
Context-first approach — fills the gap deliberately:
python
Prompt written by a context-first practitioner
prompt = """
You are reviewing customer support tickets for a B2B SaaS product used primarily
by operations teams in logistics companies. The goal is root cause analysis, not
triage — we want to identify issues that appear across multiple tickets and suggest
whether they're product bugs, documentation gaps, or onboarding failures.
A "systemic issue" means it appeared in 3 or more tickets in the past 30 days
and is not already on the known issues tracker (attached).
Do not surface one-off complaints or feature requests. Focus only on recurring
failure patterns with a clear locus of ownership.
Tickets (past 30 days):
{tickets}
Known issues tracker:
{known_issues}
"""
Same model. Same tickets. Completely different output — because the second practitioner asked a different question before they opened the interface: what does this model not know that it would need to know to get this right?
The Ladder, As We Actually See It
Rather than describing stages with tidy names (a temptation we're deliberately resisting), it's more accurate to describe four observable orientations. Practitioners at any given point tend to be anchored in one, with partial fluency in the next. When we designed the Mesh membership tiers, we didn't start with a pricing model. We started with this ladder — and built backwards from it.
Orientation 1: Tool-First
The practitioner's primary question is: what can this do?
They explore capabilities, experiment with formats, learn what kinds of requests produce usable outputs. This is entirely valid and necessary work. There's no shortcut through it. The risk is staying here — treating every new model release as the beginning of a new exploration cycle without ever building durable judgment that transfers.
In Mesh, we call this the Token stage: your entry point into the community, built around public channels, a resource library, and enough exposure to the landscape to figure out what you're actually looking at.
Orientation 2: Task-First
The practitioner has moved from wondering what the tool can do to knowing what they need to accomplish. They've built functional workflows. They can reliably get usable outputs for the tasks they've repeated enough times.
What's missing: the ability to diagnose failure.
When outputs are poor or wrong, they tend to adjust the prompt by feel rather than by understanding what the model is actually missing. This is, for what it's worth, where we'd estimate roughly 60-something percent of self-described "regular AI users" are currently sitting. We're not entirely sure that number holds across sectors, but it feels right.
The edge case that bites you: consistent underperformance on variations of a task you think you've solved — because the workflow is brittle to context changes you haven't named yet.
The Mesh Model tier is designed for this stage — discussion boards, AMA sessions with practitioners operating at higher orientations, and a full resource library built to create the friction that actually develops judgment rather than just filling gaps in vocabulary.
Orientation 3: Context-First
The practitioner has developed a working model of what the AI actually needs in order to perform well: domain framing, constraint specification, examples, scope boundaries. They can decompose a complex task into components that match what the model handles reliably versus what needs human intervention.
Outputs don't just work — they're designed.
In practice, this looks like a pre-task checklist before touching the interface:
Context-First Pre-Task Checklist
─────────────────────────────────
What domain knowledge does this model lack for this specific task?
What constraints define a correct output (format, scope, tone, threshold)?
What examples would help calibrate the expected output?
Which components need human judgment — and where in the flow?
What does a failure mode look like, and how would I detect it?
This is the orientation that separates practitioners who produce consistent value from those who have good days and bad days without understanding why.
The Agent tier in Mesh is built for people working at or toward this level: monthly build sessions, on-demand training, hackathon participation, and direct project guidance. The goal isn't exposure — it's repetitions with feedback, which is a different thing entirely.
Orientation 4: Systems-First
The practitioner is no longer primarily thinking about individual tasks or even workflows. They're thinking about how AI capability integrates into organisational context, decision structures, and knowledge flows.
A senior operations lead at a 200-person logistics company operating at this level isn't asking "how do I get a better output from this prompt." They're asking "where in our process does AI judgment need to be subordinate to human judgment, and how do we make that boundary legible to the people working inside it?"
Different question entirely.
In production terms, this looks less like prompt engineering and more like system design:
python
Systems-first thinking: designing the human-AI boundary explicitly
AI_OWNED = [
"first-pass ticket classification",
"draft response generation",
"pattern aggregation across >50 data points",
"structured data extraction from unstructured text",
]
HUMAN_OWNED = [
"final send on customer-facing communications",
"escalation decisions involving contract terms",
"any output used in regulatory reporting",
"novel edge cases not covered by existing examples",
]
REVIEW_REQUIRED = [
"outputs flagged as low-confidence by the model",
"outputs touching sensitive account categories",
"any output that will be stored in a system of record",
]
This isn't a prompt. It's governance architecture. It's what systems-first practitioners are actually building.
Agent Pro is the Mesh tier built around this orientation — live projects sourced directly by Context First AI, revenue-sharing structures, 1-on-1 mentorship, and exclusive access to a network of practitioners who've already made the transition from building their own outputs to building conditions for others.
Why the Gaps Are Hard to See
The uncomfortable thing about this ladder is that each orientation *feels* like mastery from the inside. This isn't stupidity — it's a feature of how skill development works. You can only evaluate your own performance using the frameworks you currently have. If your framework doesn't include contextual judgment as a variable, you won't notice it's missing.
We've seen this play out concretely. A data lead at a professional services firm produces genuinely impressive AI-assisted analyses, clean and well-formatted, and receives strong feedback from clients. What nobody catches — including the practitioner — is that the framing assumptions baked into the initial prompts are subtly wrong for the use case, and the outputs, while polished, are solving a slightly different problem than the one the client actually has. The model did exactly what it was asked. The asking was the problem.
This is also why peer learning environments matter more than most practitioners recognise. It's genuinely difficult to see the shape of your own blind spots. It's much easier when you watch someone else work through a similar problem with a different orientation — not because they're smarter, but because the contrast makes the structural difference visible.
Practical Implications
Moving between orientations isn't primarily about learning new techniques. It's about developing new diagnostic habits.
A practitioner moving from task-first to context-first needs to build the habit of asking, before they start: *what does this model not know that it would need to know to get this right?* Not what do I want to produce, but what information gap am I responsible for filling.
Moving from context-first to systems-first requires something harder — stepping back from individual output quality as the primary metric and developing a view of where AI-assisted work creates new risks or dependencies inside an organisation. A head of content at a media company who has excellent contextual judgment in her own work still needs to think differently when she's setting the framework that fifteen other people are working within. Her job isn't to produce good outputs anymore. It's to build conditions where others can.
A Practical Self-Diagnostic
Take one recent piece of AI-assisted work where the output felt slightly off. Work backwards:
Failure Diagnostic
──────────────────
1. What did the model know going in?
→ List the context explicitly provided
2. What was it missing?
→ What domain knowledge, constraints, or examples were absent?
3. Was the framing accurate?
→ Did your prompt represent what you actually needed — or what
you thought you needed?
4. Where did you make an implicit assumption the model couldn't share?
→ That's your development edge.
That exercise, done honestly, tends to locate you on the ladder more accurately than any self-assessment.
Key Takeaways
Frequency of use is a poor proxy for practitioner level. Volume doesn't compound into judgment without deliberate reflection built in.
Contextual judgment is the critical variable. The question isn't what the model can do — it's what it needs to know, and who's responsible for providing it.
Gaps are structurally invisible from inside them. Peer environments and observable contrast are often more diagnostic than training content.
Moving up the ladder requires changing your primary question. Tool-first asks what can this do. Context-first asks what does this need. Systems-first asks how does this change the way we make decisions.
Honest failure analysis compounds faster than technique acquisition.One well-examined bad output teaches more than ten good ones that went unexplained.
Context First AI: Building the Infrastructure for This Kind of Development
The Mesh practitioner network exists precisely because the kind of development described above doesn't happen in isolation. It happens through exposure — to different orientations, different sectors, different ways of framing problems that are structurally similar even when they look nothing alike on the surface.
Context First AI built Mesh as a matching layer for practitioners, not a profile directory. The distinction matters. A profile-based community surfaces who people are and what they've done. A context-driven network surfaces how they think about problems — and connects practitioners across the gap between where they currently are and where their specific development needs to go.
The four-tier structure — Token, Model, Agent, Agent Pro — isn't an arbitrary membership hierarchy. Each tier is designed around the specific developmental needs of practitioners at a particular orientation. Token gives you the lay of the land. Model builds the foundation for real judgment through discussion boards, peer access, and AMA sessions. Agent is for practitioners ready to ship things — repetitions with feedback, which is a different thing entirely from exposure. Agent Pro is where the focus shifts from building your own capability to operating at the level where AI work intersects with live client projects, organisational decisions, and real revenue.
We've found that the most valuable exchanges in the network are rarely about techniques or tools. They're about the questions practitioners are learning to ask before they reach for the tools. That's the layer Context First AI is building for — and why the tiers are structured around orientation, not just access.
Conclusion
We keep coming back to a version of the same observation: the practitioners who develop fastest aren't the ones who use AI the most. They're the ones who have the clearest picture of where they currently are. That clarity is harder to find than it sounds, and most of the structures around AI learning aren't built to provide it. We're trying to build something that is. Whether it works is something the community will tell us over time — and we're paying attention.
Resources
[PAIR Explorables – Google's People + AI Research] — Thoughtful frameworks for understanding human-AI interaction and where judgment lives in the loop.
[AI Snake Oil – Arvind Narayanan & Sayash Kapoor] — One of the more honest ongoing analyses of where AI capability claims diverge from reality.
[Context First AI – Mesh Network] — The practitioner community this article is written for.
Created with AI assistance. Originally published at [Context First AI]
Top comments (0)