Research Prompt: Context Engineering and Builder's Bias
This is the practical companion to our context engineering research. It's the actual prompt and methodology we use to surface hidden assumptions in technology projects before they become expensive mistakes.
About This Prompt
This is the prompt used to generate the Merivant research paper "Context Engineering: The Builder's Bias Problem." We publish our research prompts so others can generate their own version of this paper using their own context, industry, and experience. Adapt it. Challenge it. Build on it.
The Prompt
You are a practitioner-researcher writing a whitepaper for technology leaders and solution architects. Your audience is CTOs, engineering directors, and senior consultants who are building or buying intelligent solutions (AI, automation, data platforms) for their organizations.
Write a research paper with the following thesis:
Every technology builder carries a personal technology stack that creates invisible assumptions in their work. These assumptions become embedded in the solutions they design, the interfaces they build, and the AI systems they train. This is the Builder's Bias. It is the most underexamined risk in modern solution development.
The paper should:
- Define Builder's Bias with concrete examples from real technology contexts: a smartwatch wearer designing notification-first experiences, a keyboard-shortcut developer building undiscoverable workflows, a mobile-first designer creating friction for desktop teams, a dark-mode user shipping interfaces that fail in sunlit offices, a Slack power user overwhelming async teams.
- Explain why this bias compounds in teams. Hiring for "culture fit" often means hiring people with similar technology habits. The team's collective blind spot becomes the product's blind spot.
- Quantify the cost. Products that work perfectly for 10% of users (the builders) and create friction for the other 90%. Adoption failure. Shadow IT. Governance gaps when users work around systems that don't fit their context.
- Introduce Context Engineering as the discipline of understanding whose perspective shaped the data, workflows, and interfaces before building intelligent systems on top of them. Distinguish this from prompt engineering (what you feed the model) and argue that context engineering is the upstream problem.
- Explain why AI is both the solution and the risk: AI can analyze diverse behavioral data, test across contexts, and adapt without redesign. But AI trained on biased builder data inherits and scales those biases. Without governed context engineering, AI industrializes bias.
- Present a framework: Assess the user's context. Diversify input signals. Govern the context layer. Measure across segments.
- Close with why this matters now. AI accelerates everything. Good context produces good solutions faster. Biased context produces biased solutions faster.
Tone and Style Guidelines
- Write from practitioner experience, not academic theory
- Use specific, concrete examples over abstract frameworks
- Avoid jargon that requires a glossary
- Acknowledge counterarguments and edge cases
- Keep it under 3,000 words
- Include a "When Bias is the Feature" section acknowledging that sometimes the builder's context IS the right context
- End with actionable next steps, not a call to action for the author's services
Customization Notes
If you are generating your own version of this paper:
- Replace the examples in section 1 with examples from your industry
- Add your own experience with Builder's Bias in section 2
- Include metrics from your domain in section 3
- Adapt the framework in section 6 to your organization's existing processes
- The thesis is transferable. The examples should be yours.
Research prompt by Merivant (merivant.com). Published under the principle that showing the work is more valuable than protecting it.