Most organizations struggling with AI tools are not failing because the models are weak.
They’re failing because they still think of artificial intelligence as a plug-and-play widget. They believe it magically produces value without much thought given to how it’s integrated into real work.
That’s the real lesson distributed teams solved long before AI ever became mainstream: Having the right information (context) about the work you’re doing matters more than sitting physically close in an office.
What Is Context Engineering? How Is it Different From Prompt Engineering?
Context engineering is the practice of turning organizational knowledge into structured, reusable context that AI can reliably work with. When done well, this context is actively maintained, stays relevant and compounds in value as new information is added. Prompt engineering focuses on crafting individual inputs for a single interaction, whereas context engineering builds durable infrastructure and organizational memory that keeps helping.
Distributed Teams Already Solved This Problem
Remote and async teams can’t rely on informal chats, whiteboard sessions or water-cooler conversations to transfer knowledge. Assumptions, guidelines and decisions need to be written down, accessible and traceable.
This isn’t documentation for documentation’s sake. It’s the foundation of how work gets done in a distributed environment. Information is written down, work becomes clearer and guesswork, ambiguity and the silent assumptions are all reduced.
AI models don’t yet have as much intuition as humans do. They can’t “fill in the blanks” the way people can. If you don’t supply context, they invent it. That’s how you end up with hallucinations and irrelevant results.
In-office teams often get away with weak context because informal conversations paper over the gaps. The information still exists, but it’s trapped in people’s heads. AI doesn’t have that luxury. If you don’t provide the context, AI simply doesn’t have enough information to do the job well and it has to make too many assumptions.
People Don’t Fail With AI Because Models Are Weak
Most people who try AI, report poor ROI and then give up, don’t “fail” because the models are bad. They fail because they’re too inexperienced or lazy to provide sufficient context. A vague prompt translates into a vague response, and the user blames the tool.
That’s backward. AI output quality is directly proportional to the quality of the context it either already has or that it receives. Give an AI model broad, shallow prompts, and you’ll often get broad, shallow responses, no matter how sophisticated the model is. Often, the error rate is just high enough that editing the output becomes as tedious as doing the work from scratch yourself, sometimes more so.
The same thing happens with humans, but we are far more forgiving. Imagine a new team member who knows nothing about your business and whose output is mediocre in the first week. Most employers would defend that human vigorously: “It’s just their first week! They need time to learn how we do things first!” They would then show them what good work looks like, share background on how decisions are made and maybe pair them with someone who already does the job well or put them through formal training. Poor early output is treated as a signal to provide more context.
With AI, people often do the opposite. We expect instant excellence, and when the result disappoints, we show it the door.
The Same Problem Exists With Onboarding Humans
I’ve been an advocate of distributed work for a long time. In 2016, years before Covid normalized it, we scaled a business from two people working in my bedroom to a fully distributed team of more than 120 people globally.
I saw firsthand that the most common mistake companies make with remote workers is assuming they should “just get the work done.” Compare that belief to the way companies onboard in-office employees. There’s often a week of onboarding, including dinners to embed culture, training via shadowing teammates, all of which involves sharing context about how decisions are made and what the work actually is.
With contractors or remote hires, companies often skip all of that context-sharing. Leaders then act surprised when they get disappointing outcomes. A contractor may often struggle not due to incompetence, but rather due to a lack of vital organizational context. AI is no different.
The Best Outcomes Come From Deep Context
The simplest way to improve AI output is to spend time writing context and asking an LLM to help refine it. A good first step before running the final prompt is a question like, “What else should I add to my prompt to give me a better outcome?” That will help, but it’s still beginner level.
The real change comes when you stop treating prompts as one-offs, i.e., typing a prompt once, geting an answer, then moving on. Instead, you start treating context as infrastructure by investing in detailed documentation with examples of what good work looks like.
At GitLaw, we write specs for almost everything. Product behavior, workflows, edge cases, assumptions. These specs live as Markdown files in a repository. We then attach this documentation when we ask the LLM a question and often expand the prompt from one sentence into several hundred words to explain what we expect back.
We’re not alone, and this practice is often referred to as “spec-driven development,” or SDD for short. Specs are written before code, and in a format like Markdown files (.md) that LLMs can easily read. We structure them deliberately so that large language models can consume them effectively. Each section is written to stand on its own, while pointing to shared background where needed. That makes context composable, meaning we can include just the pieces the model needs for a specific task. We then ask questions like:
- How should this feature work?
- What edge cases are missing?
- Write the code for this component
We then pass the relevant parts of the spec into the model. The difference is night and day.
Spec-driven workflows dramatically reduce redundant work, misalignment and silent assumptions. It does so because we discover ambiguity early, before we write any code, before any work is duplicated and before opinions harden.
For example, we might ask an LLM a simple question:
“What features should be free versus paid?”
Without any business context, the model typically gives a generic answer that follows common SaaS patterns. When we attach a spec that clearly documents the target customer, the competitive landscape and the company’s goals, the answer changes: “Given that the target user is an early-stage founder, competitors charge high upfront fees and the goal is to build trust and adoption first, core creation should be free while advanced workflows and scale are paid.” The spec turns a vague best-practice response into a concrete, aligned decision. The more context we provide about our software, customers and goals, the better the response becomes.
This approach applies far beyond engineering. We use it for legal and operational playbooks, hiring scorecards, marketing and sales material.
Your Organizational Memory Is Your Key Asset
When people talk about “AI context,” they often imagine something magical or opaque. In practice, it’s simpler. Context is just well-maintained artefacts. Specs, playbooks and decision logs need to be kept up to date to reflect how you want work to actually be done so you can share them with humans or machines.
Models will continue to get better, faster, cheaper and more capable. The models are also basically interchangeable most of the time. Your business’s context isn’t.
High-quality, structured, up-to-date context is expensive to create and maintain. And that’s exactly why it matters.
The future of work isn’t prompt engineering. It’s context engineering.
The teams that win won’t be the ones with the best models. They’ll be the ones who know how to give them something worth working with.
