As the World Cup gets closer, football gives us another lesson for enterprise AI.

Before a big match, a serious coach does not just bring a playbook.

He studies the team.

Who can handle pressure?
Who loses the ball when the game gets fast?
Who needs simple instructions?
Who can improvise?
Who understands the system?
Who only memorized the drill?
Who is ready to play differently?
And who still needs coaching before the first whistle?

That is where matches are often won or lost.

Not on the tactical board.

In the diagnosis.

Because the same plan can look brilliant with one team and completely break with another.

AI adoption works the same way.

A copilot does not create the same result in every team.

An agent does not improve every workflow just because it is powerful.

A prompt guide does not help much if people do not know what good output looks like.

A policy does not create judgment.

And a spec-driven workflow does not accelerate delivery if the team does not yet know how to write, read, challenge, and evolve specifications.

This is the third lesson of The Human-AI Playbook:

The same playbook will not work for every team.

Context decides how AI performs.

AI adoption is not plug-and-play

Many AI adoption efforts do not fail because the tool is weak.

They fail because the organization assumes the team is ready.

AI does not enter the organization through a clean demo.

It enters the daily work.

The backlog.
The code review.
The unclear requirement.
The production incident.
The client change.
The deadline nobody wants to move.

If that work has enough clarity, AI can amplify it.

If the work is already fragmented, AI may only make the fragmentation move faster.

That is why AI adoption is never only technical.

It is contextual.

A tool can be objectively powerful and still fail inside a team that lacks shared context, clear decision rights, verification routines, or confidence in how to use it.

A prompt can be well written and still produce poor results if the person using it lacks domain knowledge, architectural understanding, or the ability to evaluate the answer.

A spec-driven workflow can be excellent in one organization and ineffective in another if the team does not yet know how to create, interpret, verify, and evolve specifications.

In football, a tactical board is not enough.

The players have to understand it.

They have to practice it.

They have to adapt it to the match.

AI works the same way.

What is a context window in generative AI?

In generative AI, the context window is the amount and type of information the model can consider at a given moment.

It includes things such as:

the user prompt,
the previous conversation,
the documents retrieved,
the code included,
the examples provided,
the system instructions,
and the relevant constraints available to the model.

The model does not “know” your organization simply because your organization exists.

It only works with the context it has access to.

If the context is incomplete, the model may fill gaps with generic assumptions.

If the context is wrong, the model may produce the wrong answer confidently.

If the context changes, the answer can change.

If critical constraints are not included, the model may ignore them.

This is why the context window is one of the most important ideas for enterprise AI adoption.

It is not only a technical limitation.

It is a design problem.

The question is not only:

How do we prompt better?

The deeper question is:

How do we make the right context available, stable, reusable, and verifiable?

Organizations also have context windows

Humans have context windows too.

A developer’s context window includes the codebase, architecture decisions, product goals, team norms, prior incidents, client expectations, security rules, and the lived experience of working inside that organization.

A junior developer has one context window.

A senior developer has another.

A product owner has another.

A QA engineer has another.

A client stakeholder has another.

A compliance officer has another.

When AI enters the workflow, all those context windows need to be coordinated.

Otherwise, the model may optimize for the prompt, while the human reviewer optimizes for quality, while the product owner optimizes for user value, while the business expects ROI, while compliance is worried about exposure.

That is not collaboration.

That is fragmentation.

Human-AI Work Design must ask:

What context does the AI need?
What context does the human need?
What context must be shared?
What context must be protected?
What context must be documented?
What context must be transformed into specifications, tests, policies, rubrics, or workflows?

What education taught us before AI

This lesson did not begin with AI.

It was already present in education, health education, digital mediation, Human-Computer interaction, and participatory design.

In my doctoral research, I studied how digital educational content could be constructed with communities, not simply delivered to them.

The problem was not whether expert knowledge was valid.

The problem was whether that knowledge could become meaningful, usable, and transformative in the lives of real people.

That distinction matters.

A health recommendation may be scientifically correct and still be contextually wrong.

A digital resource may look well designed and still fail if it ignores the culture, language, territory, economic conditions, learning history, and daily constraints of the people who are expected to use it.

In my doctoral work with women in the rural community of Granizal (Antioquia, Colombia), the construction of educational content did not begin with an expert deciding what the community “needed to know.”

It began with dialogue.

With stories.
With words used by the community.
With situations from daily life.
With local problems.
With the realities of motherhood, care, food, violence, territory, poverty, and hope.

The thesis built digital educational content from problems, needs, and meanings that emerged from the community itself — not from generic situations created by experts.

That is exactly the point for AI adoption.

A tool cannot simply be dropped into a workflow.

It must be situated.

It must be understood.

It must be appropriated.

It must become meaningful in the real context where work happens.

What is popular education?

This is where popular education becomes important.

Popular education is not “basic education” or “simplified education.”

It is a critical, participatory, dialogic approach to learning.

It starts from the reality of people.

It recognizes that learners are not empty recipients of information.

They have knowledge.
They have experience.
They have culture.
They have language.
They have questions.
They have fears.
They have constraints.
They have agency.

Popular education challenges what Paulo Freire called the “banking” model of education: the idea that experts deposit knowledge into passive learners.

Instead, it builds knowledge through dialogue.

The goal is not only to transmit information.

The goal is to help people read their reality, question it, act on it, and transform it.

In health education, this means not only saying:

“Eat this.”
“Do this.”
“Follow this guideline.”
“Change this behavior.”

It means asking:

What is possible in your life?
What do you already know?
What do you believe?
What resources do you have?
What barriers do you face?
What risks matter to you?
What changes are meaningful and achievable in your context?

This same logic was present in a framework I co-developed in Colombia for healthcare workers through the United States Agency for International Development (USAID) and the Local Health System Sustainability (LHSS) initiative, focused on community-based health education and participatory practices.

The framework emphasized dialogue, diagnosis, participatory design, implementation, evaluation, and intercultural adaptation.

This is highly relevant for AI adoption.

Because many organizations are still treating AI literacy as if it were information transfer.

A training session.
A prompt guide.
A policy document.
A tool demo.

Those things help.

But they are not enough.

People do not become AI-capable because they heard a presentation.

They become AI-capable when they learn how to use AI inside their real work, with their real constraints, their real risks, their real decisions, and their real accountability.

Example 1: Nutrition is not just a guideline

One of the clearest examples from health education is nutrition.

It is easy to say what a child “should” eat.

But real families do not live inside ideal recommendations.

They live inside territories, budgets, food availability, customs, time constraints, family structures, and caregiving routines.

As described in the USAID/LHSS manual, nutrition and caregiving practices cannot be separated from the lived realities of families and communities.

Healthy habits only become meaningful when understood within conditions such as food availability, cultural practices, caregiving routines, economic constraints, and everyday life. But interpreting those realities cannot be done arbitrarily or based only on expert assumptions. It requires participation, dialogue, and direct involvement with the people and contexts where those practices take place.

That is a powerful lesson.

A recommendation can say:

“Provide a balanced diet.”

But the real question is:

Balanced with what food?
Available where?
Affordable for whom?
Prepared by whom?
Accepted by which family?
Under which cultural practices?
With what time?
With what support?

In AI adoption, we need to ask the same kind of questions.

A leader may say:

“Use AI to write better requirements.”

But the real question is:

Which team is writing them?
What do they already understand?
What domain knowledge do they lack?
What client constraints apply?
What does the architecture allow?
What policies must be respected?
What evidence will prove the requirement is good?
Who validates it?
Who owns the final decision?

A generic AI recommendation is like a generic nutrition recommendation.

It may be technically correct.

But it will not be adopted well unless it fits the real conditions of the people using it.

Example 2: Maternal health is not just a checklist

Maternal health gives us another powerful example.

A preparation course for maternity and paternity cannot be only a checklist of clinical advice.

It needs to understand what pregnancy, maternity, paternity, childbirth, and postpartum mean for the people participating.

The USAID/LHSS manual includes a preparation course for maternity and paternity that begins with diagnosis: who the participants are, where they live, what access barriers they face, what expectations they have, what support networks exist, whether there are rural constraints, language or cultural barriers, traditional midwives or doulas, and how families understand maternity and paternity.

One activity, the “questioning fish,” invites participants to answer questions such as:

Who are the participants?
Where do they live?
What do they do?
What access do they have to prenatal, childbirth, and postpartum care?
What does maternity or paternity mean to them?
What are their expectations, interests, and needs?

That is not decoration.

That is diagnosis.

Later, when the course addresses the childbirth bag, warning signs, birth plan, postpartum care, support networks, and hospital delivery, the content is not floating in the air.

It is connected to the life of the participants.

AI adoption needs the same logic.

A company should not begin with:

“Here are the prompts everyone should use.”

It should begin with:

Who are the teams?
What are their workflows?
What decisions do they make?
What risks do they face?
What is their current baseline?
What do they fear?
What do they trust?
What do they misunderstand?
What constraints shape the work?
What does success mean in this team?

That is how adoption becomes real.

Example 3: The road with holes

One of the most memorable lessons from my doctoral work came from something very simple: an image of a road.

During the methodological process, an image of a road was used to represent the path of the project.

But the participants reacted immediately.

That was not their road.

Their road had holes.

Their road had obstacles.

Their road had difficult terrain.

So the representation had to change.

That example matters deeply.

Because it shows that context is not abstract.

People recognize when a representation does not belong to their reality.

The same happens in enterprise AI.

A generic workflow diagram may look clean.

A generic “AI adoption roadmap” may look convincing.

A generic prompt library may look productive.

But the team may look at it and think:

That is not our road.

Our road has legacy systems.
Our road has manual QA.
Our road has unclear requirements.
Our road has compliance reviews.
Our road has undocumented APIs.
Our road has junior developers learning the domain.
Our road has clients who change priorities.
Our road has production risk.
Our road has technical debt.

AI adoption fails when leaders design for the imaginary road.

Human-AI Work Design begins when we design for the real one.

From natural user interaction to situated Human-AI interaction

This lesson also connects with earlier work in Natural User Interaction and Human-Computer Interaction.

The question was never only:

Can we build an interface?

The better question was:

Can people actually use it?

In prior work that Duque and I co-developed natural user interfaces for medical appointment scheduling, the goal was to reduce the learning curve for adult users and people with low digital literacy. That research already pointed toward a social view of technology: access is not enough if the interaction does not fit the user.

This matters for AI.

A conversational interface may feel “natural.”

But natural for whom?

A chat interface may work for a senior engineer who knows how to decompose a problem, evaluate outputs, and provide context.

The same interface may be confusing for a junior developer who does not yet know what good looks like.

A voice assistant may reduce friction for one population and create privacy concerns for another.

A prompt-based workflow may empower expert users and overwhelm beginners.

The lesson from NUI is still valid:

Interaction is not universally natural.

It is task-specific, body-specific, context-specific, and capability-specific.

In the AI era, we can update that principle:

Human-AI interaction must be situated.

The interface is not only the screen.

The interface is the workflow.

The interface is the spec.

The interface is the review routine.

The interface is the policy.

The interface is the context layer.

The interface is the way humans and AI coordinate around work.

Why this matters for software teams

At Celerik, this matters because we are not only thinking about AI in theory.

We are learning from AI-assisted software delivery.

We have experimented with spec-driven workflows, AI-assisted tools, agentic execution, and internal methods for combining human judgment with machine output.

And the same pattern appears again and again:

The tool matters.

But the team context matters more.

A senior engineer with strong architecture knowledge can use AI differently from a junior engineer who is still learning the codebase.

A team with strong documentation can get more value from AI than a team where knowledge is mostly tribal.

A project with clear specs can use AI more safely than a project where requirements are ambiguous.

A regulated client requires different checkpoints than a low-risk internal prototype.

A legacy system requires different AI support than a greenfield application.

A team with strong review culture can move faster with AI than a team that treats review as an afterthought.

DORA’s research reinforces this point. AI can increase individual effectiveness, code quality, throughput, and perceived productivity, but increased adoption has also been associated with greater software delivery instability when the surrounding system is not ready.

That is why the adoption problem is not only:

How do we use AI?

It is:

How do we redesign the system so AI amplifies value instead of chaos?

Spec-driven development as context design

This is where spec-driven development becomes important.

Spec-driven development is not just writing more documentation.

It is a way of making intent explicit before execution.

In software, a specification helps define:

what we are building,
why it matters,
who it is for,
what constraints apply,
what acceptance criteria define success,
what risks must be considered,
what should not happen,
and what evidence will prove the work is complete.

In AI-assisted development, the spec becomes even more important because it makes human intent legible to AI.

A vague prompt produces vague work.

A clear spec creates a more stable basis for delegation.

This does not mean AI will always get it right.

It means humans and AI now have a shared artifact to work from.

The spec becomes a bridge between business intent, technical constraints, AI execution, and human verification.

Constitutions: making the context window less volatile

There is still a problem.

A spec helps with a single feature, story, or workflow.

But organizations need a more durable layer of context.

This is where constitutions become useful.

A constitution is a stable set of principles, rules, and constraints that the team agrees should guide AI-assisted work across many tasks.

In software, a constitution may include:

architecture principles,
security rules,
coding standards,
data privacy constraints,
compliance requirements,
quality expectations,
accessibility principles,
testing requirements,
definition of done,
review rules,
and escalation criteria.

The constitution does not replace the spec.

It surrounds it.

The spec says:

What are we building now?

The constitution says:

What rules must always shape how we build?

Together, they reduce volatility.

The AI does not have to rediscover the organization from scratch every time.

The human does not have to rewrite the same constraints in every prompt.

The team can make context reusable.

This is critical because the AI context window is temporary and bounded.

But organizational context must persist.

If the organization depends only on prompts, context becomes fragile.

If the organization creates specs, constitutions, architectural decision records, tests, policies, and evaluation rubrics, context becomes infrastructure.

That is the difference between using AI and designing AI-native work.

Human-AI Work Design starts with diagnosis

Not with a tool.

Not with a license.

Not with a prompt library.

Not with a workshop that assumes every team is ready.

It starts by understanding how work actually happens.

Where decisions get stuck.
Where requirements lose meaning.
Where documentation cannot be trusted.
Where review becomes rework.
Where people need judgment, not just automation.

Because AI does not improve work in general.

It improves, exposes, or accelerates the specific work it enters.

That is why diagnosis cannot become a shortcut.

A shallow diagnosis feels like control.

But it may only be a well-documented guess.

And when AI amplifies the wrong guess, the organization can feel productive while moving faster in the wrong direction.

This is very similar to what participatory education has always known:

You cannot design meaningful learning without understanding the learner, the context, the culture, the problem, and the conditions of action.

In enterprise AI, we should say the same:

You cannot design meaningful AI adoption without understanding the people, the workflows, the context, the constraints, and the conditions of value.

Context is not a soft variable

In many technology projects, context is treated as secondary.

Something to consider after the tool is selected.

Something for change management.

Something human resources can handle later.

That is a mistake.

Context is not soft.

Context determines whether AI output is useful, risky, generic, misleading, actionable, or transformative.

Context affects:

the quality of prompts,
the quality of specs,
the relevance of outputs,
the ability to verify,
the risk of overtrust,
the speed of adoption,
the confidence of teams,
the accuracy of measurements,
and the sustainability of value.

DORA’s ROI report makes a similar point: AI is not a standalone solution, and its returns depend on the environment it operates within — internal platforms, workflows, data quality, human capital, infrastructure, and organizational maturity.

In AI, context is technical.

In organizations, context is human.

In Human-AI Work Design, it is both.

What leaders should ask before scaling AI

Before scaling AI across teams, leaders should stop asking only:

How many licenses do we need?
Which model should we use?
How many agents should we deploy?
How many people attended training?

Those are useful questions, but they are not enough.

Better questions are:

Who are the people who will use AI?
What do they already know?
What do they need to learn?
What decisions are they responsible for?
What workflows are ready for AI?
What workflows are not ready?
What context must be available?
What should be documented?
What should become a spec?
What should become a constitution?
What must be verified?
What risks are unacceptable?
What policies shape the work?
What does success look like for this specific team?
How will we know whether AI is creating value or just producing more activity?

This is how AI adoption becomes organizational learning.

Not just tool rollout.

Not just training.

Not just automation.

But a situated, adaptive, human-centered redesign of work.

The third principle of The Human-AI Playbook

The first principle was:

11 agents are not a team.

The second principle was:

The first bad match is not failure.

The third principle is:

The same playbook won’t work for every team.

AI adoption must be adapted to the players, the field, the constraints, the culture, and the match.

A company cannot copy another company’s AI playbook and expect the same results.

A team cannot copy another team’s prompt library and expect the same outcomes.

A software agency cannot simply insert AI into old workflows and expect transformation.

A model cannot produce reliable work without context.

And humans cannot work well with AI if they are not learning, adapting, verifying, and participating in the redesign of the work.

That is why Human-AI Work Design matters.

It is not only about AI.

It is about designing the conditions under which humans and AI can learn to work together.

Work with us

If your organization is adopting AI, do not begin only with tools.

Begin with context.

At Celerik, we help organizations move from AI tool adoption to Human-AI Work Design: redesigning workflows, roles, context architectures, verification checkpoints, specs, constitutions, and capability-building systems so AI can create sustainable business value.

If your teams are using AI but getting uneven results, the problem may not be the tool.

It may be the system around the tool.

Let’s design AI adoption around your people, your context, and your work.

Follow the series

This article is part of The Human-AI Playbook, a series about how organizations can move from AI tool adoption to Human-AI Work Design.

Next up: The AI Scoreboard — Why AI Adoption Should Not Be Measured by Usage Alone