Most generative artificial intelligence (AI) workshops begin with the instructor sharing a screen. Employees watch a polished demonstration, try several prompts and leave with a resource guide. The session may earn strong satisfaction scores, yet two weeks later, few participants have changed how they work. 

I have seen that pattern often enough to stop treating awareness as the goal. Effective AI training begins when employees close the demonstration window, open a real piece of work and attempt to build something useful. 

That shift changes the role of learning and development (L&D). It becomes the architect of a safe environment where employees can examine workflows, test ideas, discover failure points and learn when human judgment must take control. 

Start With Friction Instead of Features

In client workshops, I rarely begin by asking, “What would you like AI to do?” That question produces vague answers about saving time, improving productivity or automating routine work. 

Instead, I ask participants to describe what happened during a frustrating hour in the previous week. 

The answers become specific. A purchasing employee spent 45 minutes comparing a sales report with an inventory spreadsheet. A manager rewrote six store-visit summaries because each supervisor used a different format. An HR employee answered the same benefits question for the fourth time that morning. An insurance professional searched across emails, claim notes and policy documents before responding to a customer. 

Those moments give L&D something teachable. The facilitator can help employees identify the input, decision points, exceptions and quality standards inside the work. Participants begin learning workplace AI skills while solving a problem they already understand. 

Why 90-Minute Build Labs Outperform Long Workshops

In one organization, we initially planned a half-day workshop. The agenda included AI fundamentals, demonstrations, prompting practice, governance and project development. On paper, the design looked comprehensive. In the room, participants became overloaded. 

By the time they reached their own projects, they were tired and tempted to build something broad simply to finish the exercise. One group proposed an assistant that would read operational reports, identify risks, assign follow-up work and draft an executive briefing. They had 35 minutes left and no clear way to test whether the assistant worked. 

We changed the learning design. 

Instead of one long session, we used focused 90-minute build labs. Participants arrived with one workflow selected in advance. We spent roughly 10 minutes defining the problem, 15 minutes mapping the current process, 35 minutes building, 20 minutes testing and the final 10 minutes discussing what failed. 

The energy changed immediately. Participants stopped trying to “transform” an entire function. They concentrated on producing one useful output. 

This is what builder-centered learning looks like in practice. The time limit creates productive discipline. It pushes employees to narrow the project until they can describe what success means and test it during the session. 

For L&D, the shorter format also makes observation easier. Facilitators can see where learners struggle, which instructions confuse them and what governance questions emerge. Each lab becomes both a learning intervention and a needs assessment. 

A Retail Team Learns to Narrow the Problem

In one retail organization, a purchasing employee arrived with a large spreadsheet containing product numbers, inventory counts, order quantities and delivery information. She initially wanted an AI assistant that could “manage purchasing.” When I asked her to show me the frustrating part, she scrolled to a group of rows where figures from two reports did not match. 

Her real need was much narrower. She wanted help identifying inconsistencies before sending a purchase order to accounting. The first output looked convincing but flagged too many ordinary variations as errors. The employee pointed to several rows and explained why the differences were normal during a promotion. That five-minute explanation became the most valuable part of the exercise. 

She revised the instructions to distinguish expected promotional changes from unusual discrepancies. She added a requirement that the tool identify the relevant row and explain why it had been flagged. She also retained final review rather than allowing the system to alter an order. 

By the end of the lab, she had built a small review assistant that could help her direct attention to the right places. That outcome taught more than a generic prompting exercise could. She learned that AI needed operational context, that plausible output was not necessarily useful and that testing required examples from both ordinary and unusual situations. 

For L&D, the important result was visible behavior change. The learner could now define a bounded use case, establish a review standard and explain what the tool should never do independently. 

Pre-Work Prevents the Workshop From Becoming Tech Support

Hands-on sessions often fail for mundane reasons. A participant cannot access the approved platform. Another cannot find the sample files. A third discovers that a company security setting prevents the connection needed for the exercise. When several people encounter those problems at once, the facilitator stops teaching and begins troubleshooting passwords. 

I now treat pre-work as part of the learning experience rather than an administrative afterthought. Before a build lab, participants confirm account access, locate an appropriate sample document and identify a repetitive workflow.  

This preparation makes hands-on learning more productive. It also gives facilitators early evidence about organizational barriers. If half the participants cannot access approved tools or data, the problem is not employee motivation. It is learning infrastructure. 

Responsible Learning Includes Deciding Not to Build

Builder-centered training should not reward participants solely for producing a tool. Sometimes the most mature outcome is deciding that a proposed use case should not proceed. 

During an HR workshop, a participant considered building an assistant to summarize internal conversations and identify recurring employee concerns. The potential value seemed clear. The privacy implications became clear just as quickly. 

The participant paused when considering what information the system would process, who might see the summaries and how employees would react if sensitive conversations became training data or management reports. The project stopped there. 

I considered that a successful learning outcome. 

The participant had applied responsible AI use rather than treating governance as a checklist added after development. She recognized that technical possibility did not establish organizational appropriateness. 

L&D can encourage this judgment by building a “do not build” decision into the activity. Facilitators should ask what data the tool would require, who could be harmed by an error, whether the output affects a consequential decision and whether the organization can provide meaningful human review. 

A prototype that gets abandoned because the risk is too high demonstrates capability, not failure. 

L&D Must Teach Ownership Alongside Creation

Once employees build useful tools, someone has to maintain them. 

In one company, an employee created several useful AI projects for recurring work. The arrangement seemed successful until she took a vacation. A colleague needed to update the instructions but lacked editing access. 

A learning program that teaches creation without documentation, handoff and maintenance leaves the organization with fragile capability. 

I now encourage L&D teams to include a simple ownership record with every project. The learner identifies the business purpose, approved data, current owner, backup owner, testing examples, known limitations and required review process. 

That document does not need to become a lengthy technical manual. Its purpose is to make the learning transferable. Another employee should be able to understand what the tool does, why it exists and where it may fail. 

L&D Becomes an Architect, Coach and Connector

A builder-centered approach gives L&D a more active operating role. 

Before training, L&D gathers workflow problems and screens them for suitability. During training, facilitators help employees narrow projects, define quality and test edge cases. After training, L&D connects promising prototypes with IT, security, legal or operational specialists. 

That role requires different facilitation skills from presenting software features. The instructor must be comfortable responding to a participant’s question with another question: “What would make this output unsafe?” “How would a colleague verify that?” “Which exception would cause the process to fail?” 

L&D should not attempt to replace technology or risk functions. It should create a structured bridge between them and the employees who understand the work. 

Builder-Centered Training Has Clear Limits

This approach does not fit every audience or every workflow. 

Employees should not independently deploy tools that make decisions about hiring, promotion, performance, medical care, legal conclusions, financial eligibility or other high-impact matters. Projects involving sensitive personal information, irreversible actions, complex integrations or strict audit requirements need stronger specialist control. 

A learner may still contribute valuable knowledge by mapping the workflow, identifying exceptions and developing test cases. Participation does not have to mean ownership of production development. 

The European Commission’s guidance on human-centered AI adoption emphasizes tailoring AI literacy to people’s roles, experience and risk context. L&D should make the same distinction. Some employees need independent building skills. Others need enough understanding to evaluate outputs, escalate concerns or collaborate with technical teams. 

Builder-centered learning also struggles when managers provide no time after the workshop. Employees cannot maintain useful experiments if the organization treats building as an extracurricular activity. A training program needs follow-up office hours, manager support and a route for promising projects to receive further review. 

Measure Changed Work Instead of Completed Courses

Course completion is a weak measure of AI readiness. I ask L&D teams to look for evidence of changed judgment. Can employees identify appropriate use cases? Can they describe a quality standard before prompting? Can they test unusual scenarios, detect weak output and explain when human review is required? 

Build labs also produce useful operational measures. L&D can track how many projects were narrowed, revised, transferred to regular work or intentionally abandoned. Teams can examine correction rates, time saved, repeated use and the quality of documentation. 

Not every number needs to demonstrate immediate financial return. Early measures should show that employees are becoming more discerning, not merely more enthusiastic. 

That’s why builder-centered learning works. The strongest AI learning programs give employees more than information about new technology. They give them carefully structured opportunities to build something useful, discover where it fails and improve the work they understand better than anyone else.