AMA Answer: What are some good ways to ensure that non-developers get involved in context engineering?

Full Question by Rosie Sherry: 

Response:

You don’t need to be a developer to shape context. Most of it is about decisions, and not code.
 
I am a non-developer myself in my current role at ifm. However, I keep taking up the role of a test automation developer/vibe-coder for creating utilities and solutions to help me with my testing.

There are various areas where I see myself and other non-developers getting involved in context engineering:
1. Identifying the context sources (Sources of truth) and making them visible. I use a OneNote doc for this.
2. Setting guardrails or rules for context pulling, reading, and writing.
3. Defining Order and priority of context areas. Eg, Company color guidelines are prioritized over all instructions concerning branding.
4. Starting context branches for isolated & independent contextual threads. Now, new tools allow branching discussions into a new chat.
5. Periodic context sources & instruction review loops as well as fine-tuning. I personally do this once a month for a project I am part of.
6.  Treat context like a test strategy or requirements. We have to own it, govern it, and keep it relevant.

A few tips:
> Start new chats when you shift to a fresh new context
> Condense context whenever the context windows are over 50%.
> Personalize the AI tool for your workflow and context. Look up in the settings/personalization options on these tools.
> Use markdown, lightweight, and structured context sources over a general 100 Page document uploading.
> Involve stakeholders (non-devs, business, QE, testers, etc.) when talking about context engineering.  Without them, context engineering fails.

There are certainly more things that one can do. I see this topic as a high-potential area. It's a powerful and ever-evolving space. As quality engineers, we will have a lot of work to do here.