Five engineers. Same instruction. Five completely different answers.

You could read that as a communication failure. Or you could read it as the most useful data point you’ll collect at the start of an AI transformation. I’ve come to believe it’s the latter — and that learning to read it clearly is half the work of leading a team through this shift.

The Exercise

We’re in the middle of a deliberate initiative to embed an AI-first mindset across our engineering practice. The focus areas are clear: AI-Assisted Software Development Lifecycle and AI-Assisted Site Reliability Engineering. Both have obvious applications. Both have been validated by teams doing this work at scale. The opportunity is real.

But before you can build anything useful, you have to solve a problem most transformation initiatives skip entirely: articulation. You cannot automate what you haven’t described. You cannot build a skill for a process you’ve never written down. Before your engineering team can leverage AI agents, each person needs to be able to say — with enough specificity that a system could follow it — what they actually do.

So I ran an exercise. I asked each person on the team to document a process they execute regularly, with steps, as preparation for building skills to use with our coding agent. The framing was low-pressure and intentional: this is about getting your knowledge out of your head and into a format that can be used. Think of it as writing a recipe, not a design doc. Start anywhere. Any process works.

What I expected: roughly similar responses in scope and structure. Some variance, sure, but a cluster around “here’s a daily development workflow” or “here’s how I handle a certain kind of request.”

What I got was something more interesting.

Five Windows into Five Mental Models

Each person’s response revealed where they actually are in their mental model of AI — not where they say they are, not where the company narrative says they should be, but where they genuinely live when they try to engage with this question.

The builder. One person came back with a working skill. Not a description of a hypothetical skill. Not a draft. A functional integration with the team’s code review and issue-tracking platform — capable of analyzing pull requests, synthesizing feedback, and updating the project tracking system. Steps, tool calls, outputs. This person has already internalized the agentic loop. They heard “document a process” and reached for the implementation layer because to them, the documentation is the implementation. They think in skills natively.

The extender. Another person documented improvements to skills they were already building, plus a new one for the team’s project and pipeline management platform. This response is quieter than the builder’s but equally sophisticated — it assumes a baseline of capability and focuses on the gaps. This is someone who has been iterating, who knows the terrain, and who is optimizing rather than starting from scratch. They’re in the middle of the journey, which means they’ve already done the hardest cognitive work of crossing the threshold.

The designer. A third person mapped out their full API design process — end to end, with every stage, every decision point, every handoff. Not as a working automation, but as a precise articulation of a complex, multi-stage workflow that currently takes significant manual effort. This is different from the first two. The person isn’t automating yet. But the description they produced is sharp enough that it could become the instruction set for an agent tomorrow. High-value raw material — and an honest, un-rushed answer to what the question was actually asking.

The troubleshooter. One response went straight to pain: the process of hunting for transaction data across the observability platform during an incident. Every engineer knows what this feels like — the systems are there, the data is there, but you’re navigating multiple queries, dashboards, and context-switches when your attention should be on the problem, not the tool. The precision of this answer is what makes it valuable. It’s not “I want to automate something.” It’s “here is the exact friction point where my time disappears and my frustration spikes.” That specificity is the seed of a useful skill.

The aggregator. The fifth response tackled something harder to pin down: the process of gathering requirements across multiple communication channels. Tickets. Meetings. Direct messages. Email threads. The problem isn’t that the requirements don’t exist — they do, scattered across a dozen surfaces. The problem is that assembling them into a coherent picture is a coordination tax that sits on top of every project. An agent that runs this aggregation loop would return hours every week. This response identifies a systemic problem rather than a task-level one. Different kind of answer, different kind of insight.

What the Diversity Means

The instinct when you see this kind of spread is to sort it into “good” and “not there yet.” That instinct is wrong, and it’s worth being explicit about why.

The builder and the extender are closer to execution. But the designer’s structured articulation of a complex process is exactly the kind of documentation that makes AI-assisted development stick long-term — it’s what the builder will need when they turn their skill into something the whole team can use. The troubleshooter’s precise pain map is the starting point for a skill that’s actually worth building, rather than a capability in search of a problem. The aggregator identified a problem that, once automated, will have a measurable impact on every project that follows.

None of these is “wrong.” They’re entry points on the same journey. A team where everyone gave you identical answers wouldn’t be showing you their actual mental models — it would be showing you their training in how to answer questions correctly. That’s less useful.

What the diversity actually tells you:

• Who’s already operating with agents — and can become an internal resource and model for the rest of the team
• Who has the domain knowledge to design agent workflows but needs help bridging from description to implementation
• Who knows exactly where they hurt and just needs support translating that pain into a skill
• Who is thinking at the system level rather than the task level — which is where the most durable automation lives

The starting point for a real transformation isn’t uniform readiness. It’s accurate self-knowledge. When your team can tell you where they actually are, you can meet them there.

The Articulation Channel

The first step in any agentic transformation initiative isn’t choosing a platform, picking a model, or setting up infrastructure. It’s articulation — the act of making tacit knowledge explicit.

Most engineers can execute their daily processes fluently without being able to describe them at the level of specificity an AI agent needs. The workflows are internalized. The decisions are instinctive. The edge cases live in working memory. Ask someone how they do something they’ve been doing for years and they’ll give you the general shape of it. Ask them to write it down step by step, as if explaining it to someone with no context — and the gaps appear immediately.

This is the exercise. Not because the documentation itself is the deliverable, but because the act of producing it surfaces what you know and what you assume. The knowledge you can’t describe is the knowledge your AI can’t use.

There’s a simple heuristic I’ve found cuts through any hesitation about where to start: what task takes most of your time and you most dislike? This works across the entire experience spectrum. It doesn’t require AI literacy. It doesn’t require any prior exposure to agentic tools. Every engineer has an answer — and that answer is the seed of the first useful skill.

The builder built it. The troubleshooter named it. The aggregator mapped it. Each of them answered that question in their own way. As directing agents starts with knowing what to direct them toward, the practice of articulation is the practice of knowing. It comes first.

The Immersion Gap

Here’s the honest challenge I don’t see discussed enough in AI transformation writing.

When you’ve been embedded in this space since the GPT breakthrough — running agentic workflows, building personal AI infrastructure, iterating on prompts and tools for years — it becomes genuinely difficult to reconstruct what “AI is external and weird” feels like. The accumulated context becomes invisible to you. You can’t easily unpack the stack of failed experiments, iterated approaches, and internalized patterns that make your instincts feel obvious, and hand that stack to someone else.

This is the curse of knowledge: the expert’s difficulty imagining the novice’s perspective. Not a character flaw. A cognitive phenomenon that gets worse the deeper in you go.

The gap between someone two-plus years into daily agentic development and someone who’s just beginning to map their first process isn’t an intelligence gap or a capability gap. It’s a context accumulation gap. The early practitioner has built a mental model that took years of hands-on iteration to develop. They can’t simply describe it to you in a meeting. They can only show you evidence of it in the work they produce.

I think about this every time I sit with a team member who’s still experiencing AI as something separate from their workflow — something that might work for other people, in other contexts, but hasn’t clicked as a native capability. From where I sit, the path forward is obvious. I can see the use cases, the workflow integrations, the time savings. From where they sit, they’re being asked to describe a process they can do in their sleep in enough detail to program a system they don’t fully understand yet. That’s a significant cognitive ask.

What actually works isn’t more explanation. It’s the exercise itself. When the builder documents a working skill and the troubleshooter documents a pain map, they’re both answering the same question in the same format. That shared format is the beginning of a shared language. The perception gap between deep practitioners and cautious adopters runs in both directions — the practitioner loses visibility into what it was like not to know, just as the hesitant adopter may underestimate what they’re leaving on the table. The exercise creates common ground that explanation alone can’t.

Progress Is the Point

Just completing the exercise is a transfer of the most important underlying skill: the ability to describe what you do precisely enough that someone — or something — else could do it.

The no-code and low-code agentic platforms we’re working with today require this skill. The pro-code agentic solutions we’ll build for internal customers tomorrow require it more. When you commission an agent to handle a workflow, you have to be able to describe that workflow at a level of precision that your current tooling will accept. You have to know what done looks like. You have to anticipate the edge cases the agent will encounter.

Articulation isn’t a warm-up act. It’s the core competency.

Every response I received from the team was valid. The working skill. The improvement proposal. The future-state API design. The pain map. The coordination nightmare. Each one moved someone from “AI is a thing that exists outside my work” toward “AI is a tool I can direct with a description I can write.” That movement, regardless of the distance covered, is the transformation.

The teams that get to pro-code agentic solutions fastest won’t be the ones with the most AI literacy upfront. They’ll be the ones who got good at articulation early — who built the habit of describing their work precisely, surfacing the friction points, and translating “I hate doing this” into “here’s exactly what this involves.”

That’s what the exercise is building. And the team that finishes it has already done something harder than it looks.

The Next Step

The follow-on prompt for the next session is one notch further: From everything you documented, pick one step you’d hand to an agent first. Not the whole workflow. One step.

The distance between “here’s my process” and “here’s the first step I’d delegate” is smaller than it looks. The people who got to working skills in round one will help others cross it. The knowledge in the team is already there. The exercise is just the mechanism for getting it out.

---

If you’re working through an AI transformation in a regulated or enterprise environment, I’d be curious what you’re finding in the articulation phase — where the gaps show up and what’s actually helped. Find me on X @orestesgarcia or LinkedIn /in/setsero.

Related: Everything Is Skill Issue — on the organizational resistance that surrounds every AI adoption curve, and why the perception gap runs in both directions.