By Marc Boudria, Chief Innovation Officer at Betterengineer.com
People across your organization are already experimenting with AI. Developers are using coding assistants. Sales teams are testing outreach prompts. Support teams are summarizing tickets. Operations teams are automating repetitive work.
Some of it is risky. Some of it is happening in tools that leadership has never approved.
The question is not whether people should explore AI. They already are. The real question is whether that exploration is happening in a way the organization can learn from, govern, and turn into real capability.
The answer is controlled experimentation. Use AI, but think critically about the output. Here are 7 experiments to get you started.
The weakest AI experiments usually start with a vague mandate: “Let’s try AI.” That is not a problem statement. That is enthusiasm without direction.
A useful experiment starts with a specific workflow or pain point:
Now you have something to test. Responsible experimentation begins with a clear problem, a defined boundary, and an environment where the team can explore without touching production systems or exposing real data.
That is where the DevOps sandbox matters. Experimentation without a sandbox is just recklessness with better branding. If people are going to test AI-assisted workflows, they need a safe environment where they can break things, test assumptions, use synthetic data, and learn without putting the business at risk.
The sandbox is what makes responsible curiosity possible.
Synthetic data generation is one of the safest places to begin because it lets teams explore AI without exposing real customer, employee, or business data.
Support can generate realistic ticket scenarios. Sales can create fictional lead records. Product can generate sample user feedback. QA can create test cases. Operations can model fake records that resemble the structure of real workflows.
The point is not that synthetic data is perfect. It is not. The point is that it helps teams learn how to describe the shape of their work without touching sensitive information.
This is also a useful training exercise. Teams quickly learn that vague prompts produce vague data, while specific context produces more useful outputs. That lesson applies to almost every AI use case.
What to learn from it:
Did the synthetic data resemble the real workflow closely enough to be useful? What was missing? Where did the AI invent unrealistic details? What would need to be validated before using this pattern in a real process?
This experiment pairs a developer with a non-developer who owns a business problem. The non-developer explains the workflow, the friction, and the desired outcome. The developer uses AI to explore possible approaches, sketch logic, identify edge cases, or build a lightweight prototype.
The key rule is simple: the developer must understand what gets generated. If the developer is just copy-pasting AI output and then debugging something they never understood, the experiment has failed. That may create motion, but it does not create capability.
The value here is not proving that AI can generate code. Everyone has seen that demo. The value is seeing whether AI can help a technical and non-technical person think through a problem together more clearly.
The non-developer brings operational context. The developer brings technical judgment. AI helps accelerate the conversation, but it does not replace either person’s responsibility to think.
What to learn from it:
Did AI help clarify the problem? Did it suggest anything useful? Did it miss important constraints? Could the developer explain the output? Did the business stakeholder leave with a better understanding of what it would take to build?
Most organizations are full of repetitive workflows that people complain about, but no one has properly documented. These are often good candidates for AI exploration, but not every repetitive task should be automated.
This experiment asks a team to identify one repetitive task and work with a technical partner to prototype an AI-assisted version in a sandbox.
A sales team might test account research summaries. A support team might test ticket classification. A design team might test first-pass content variations. An operations team might test document intake or spreadsheet cleanup.
The goal is not to ship the automation. The goal is to learn whether the workflow is worth automating at all.
Some workflows look simple until you inspect them. They may depend on human judgment, inconsistent data, undocumented exceptions, or business context that is hard to encode. Discovering that early is valuable. It prevents the organization from investing in the wrong thing.
What to learn from it:
Did the prototype reduce effort or just move the effort somewhere else? Did it improve quality? What new review burden did it create? What would break if this touched production? Where does human judgment still need to stay in the loop?
Some of your people are probably already using AI tools you did not approve. That does not mean they are being reckless. Often, it means they are trying to solve real problems faster than the organization is providing solutions. But it does create risk, especially if people are entering company data, customer information, or proprietary material into unsanctioned tools.
Instead of pretending this is not happening, create a temporary, non-punitive audit. Ask people what tools they are using, what they are using them for, what data they are entering, and what problems those tools are solving. The goal is not to punish people. The goal is to understand where unmet needs already exist.
Some tools may be safe to formalize. Some may need to be replaced. Some use cases may deserve investment. Others may need to stop immediately.
What to learn from it:
What are people already doing with AI? What problems are they trying to solve? What data is being exposed? Which use cases are legitimate? Which are unsafe? What internal guidance or tooling was missing?
For most employees, the important skill is not “prompt engineering” in some overcomplicated sense. The important skill is learning how to ask better questions, provide useful context, constrain the output, and evaluate whether the answer is any good. That last part matters most.
AI can produce polished nonsense. It can sound confident while missing the actual business context. It can flatten nuance, invent details, or skip over the most important constraint. If employees are not trained to challenge the output, they will mistake fluency for accuracy.
This experiment teaches non-technical teams how to interact with AI more responsibly. They should learn how to define the task, provide context, state constraints, ask for assumptions, request structure, and critique the result before using it.
For example, a support manager should not simply ask AI to “write a response to this customer.” A better request would include the customer context, the policy boundary, the desired tone, escalation criteria, and a request for the AI to identify missing information before drafting.
What to learn from it:
Did better prompting improve output quality? Did employees become better at spotting weak answers? Did they understand when not to use AI? Which workflows benefited from AI assistance, and which introduced too much risk?
If people have no legitimate path to propose AI ideas, they will either stop bringing ideas forward or start testing them quietly on their own. Neither is good.
This experiment creates a lightweight proposal process for AI ideas across the organization. It does not need to be a giant committee or a six-month review cycle. It just needs enough structure to help people turn curiosity into a testable experiment.
A useful AI experiment proposal should answer:
This gives non-technical teams a way to participate without going around engineering. It also gives engineering, DevOps, and security enough visibility to guide the experiment safely.
What to learn from it:
Did the proposal clarify the idea? Was the team able to define success? Did technical reviewers have enough information to evaluate feasibility? Did the process encourage useful experimentation without creating unnecessary drag?
Most organizations already have an AI experiment that went sideways.
Maybe someone built a prototype that broke immediately. Maybe AI-generated code introduced technical debt. Maybe a tool was used with data it should not have touched. Maybe a demo quietly became part of a real workflow. Maybe a developer accepted generated output they did not understand and then lost hours trying to debug it.
Do not bury that story. Study it.
The goal is not to embarrass anyone. The goal is to understand what failed in the process.
Was there no sandbox? Was real data used when synthetic data would have worked? Was there no technical review? Did leadership mistake a prototype for a product? Did someone trust AI output because it looked polished? Were the rules unclear?
A good post-mortem should produce better guardrails, not fear. It should help the organization understand how to experiment more safely next time.
What to learn from it:
What would have caught the issue earlier? What guardrail was missing? What assumption proved false? What decision created the most risk? How can the process improve without shutting down useful exploration?
The value of these experiments is not just the prototype. In many cases, the prototype may be the least important outcome.
The real value is what the organization learns.
You learn where AI can genuinely reduce effort. You learn where it creates new risks. You learn which workflows are poorly understood. You learn where data quality is not ready. You learn which teams are thinking critically and which ones are treating AI as a shortcut around understanding.
That last point is critical.
AI does not remove the need for expertise. It increases the need for expertise because someone still has to know whether the output is useful, safe, accurate, and appropriate for the business context.
The organizations that build real AI capability will not be the ones chasing every new tool or banning every experiment. They will be the ones that create enough structure to learn quickly without losing control.
Do not try to do all seven at once.
Pick one experiment and run it in the next 30 days. Choose something small enough to manage but real enough to matter. Define the problem. Use a sandbox. Bring the right people into the room. Use synthetic data where possible. Document what happens. Debrief honestly.
The goal is not perfection. The goal is to build organizational muscle for thinking critically about AI.
At BetterEngineer, we help organizations design, run, and evaluate these kinds of AI experiments. We can help you create the sandbox, structure the intake process, bring technical and cross-functional teams together, and turn scattered curiosity into disciplined capability.
Start small. Learn something real. Then decide what deserves to come next.