TL;DR: Build or buy AI is the wrong framing for most organizations. Buying an AI tool solves one problem at one moment. Teaching employees to build creates capability that compounds. Behavioral scientist Dr. Gleb Tsipursky argues the people who understand the work should help design, test, and improve the AI tools they use, inside clear guardrails.
The line I keep going over from Dr. Gleb’s piece is this one is that your company owns the licenses, but the vendor owns the practical knowledge.
I believe we’re in an era of building. And the sooner our people understand what building with AI actually looks like, the sooner they start wearing that hat, asking what’s possible now instead of staying stuck inside the box of what used to be possible. That shift is worth more than any single tool you’ll buy this year, which is part of why so many AI investments produce nothing while the license renews on schedule.
I want to complicate this before you read it, though, because this is the work I do for a living. So does Gleb, for what it’s worth, which means you’re about to get advice about outside help from two people who sell it. Read us accordingly. I’m not saying every employee should be writing code or unclogging it. Most of what an organization actually puts into production still needs professionals, because of the sheer volume of guardrails and security work it takes to make something genuinely useful instead of a high-risk hazard sitting inside your business. That part doesn’t go away, and anyone who tells you it does is selling something.
But understanding what’s buildable? That should be open to everybody. I’ve watched my seven-year-old build a working app in twelve minutes, so the ceiling is not where most of us think it is. Let’s open the gates, especially for the small and mid-sized organizations that keep getting told this stuff is out of reach.
If you want to work out where that line sits for your own team, what to hand off and what to keep in your own hands, that's what we build in the AI Judgment Workshop.
Ninety minutes live, $99, and you leave with a written 90-day plan.
Dr. Gleb Tsipursky is a behavioral scientist who was called the “Office Whisperer” by The New York Times, and he’s held faculty appointments at Ohio State and the University of North Carolina at Chapel Hill. His book The Psychology of AI Adoption at Work: From Resistance to Results comes out with Georgetown University Press in September 2026.
Here’s Gleb.
Stop Renting Your AI Capability: Teach Your Employees to Build AI Tools
Most organizations approach artificial intelligence as something they must buy from someone else.
A vendor demonstrates an impressive platform. A consulting firm proposes a custom solution. Leadership approves the contract, employees receive access, and everyone waits for transformation to happen.
Then the organization discovers the hidden cost. Every adjustment requires another vendor meeting. Every new workflow requires another statement of work. Employees understand the business problem but cannot modify the solution. The company owns licenses, yet the vendor owns the practical knowledge.
That arrangement may deliver a tool. It rarely creates internal AI capability.
The stronger alternative involves teaching employees to help design, build, test, and improve the AI tools they use. Leaders should still rely on technical experts for architecture, security, complex integrations, and high-risk systems. However, they should stop assuming that every useful AI solution must arrive as a finished product from an outside provider.
The Difference Between Buying Tools and Building Capability
Buying an AI tool solves a defined problem at a specific moment. Building capability changes how the organization responds to problems for years.
The distinction matters because AI tools and business needs evolve quickly. A vendor-built assistant may fit today’s workflow, but employees will soon identify exceptions, new applications, and better ways to use it. When only the vendor can make changes, the organization moves at the speed of procurement.
An organization with employee AI builders can move differently. Employees who understand customer complaints, compliance reviews, scheduling bottlenecks, or membership requests can turn proven prompts and workflows into repeatable internal assistants. They do not need to become software engineers. They need enough support, access, and governance to translate their expertise into useful tools.
This approach also changes the psychology of adoption. Employees experience AI as something they shape rather than something management imposes on them.
That shift creates ownership.
Why Domain Experts Often Build the Most Useful Tools
Outside developers may understand the technology better than your staff. Your staff understands the work better than outside developers.
The claims processor knows which parts of a file require judgment. The customer-service representative knows which questions waste the most time. The HR coordinator knows where onboarding repeatedly breaks down. The project manager knows which reports consume hours without improving decisions.
These employees possess what consultants often spend weeks trying to extract: operational knowledge.
Research on generative AI productivity illustrates why this knowledge matters. In a study of 5,179 customer-support agents, access to an AI assistant increased productivity by 14 percent on average, with much larger gains among less-experienced workers. The system helped spread practices associated with more capable employees.
That finding points toward a broader lesson. AI produces greater value when organizations capture internal expertise and make it reusable.
An employee-built intake assistant, reporting copilot, or policy guide can encode the organization’s actual language, standards, common exceptions, and review process. A generic vendor product usually starts farther away from that reality.
Start With the Task Employees Already Want to Eliminate
Leaders frequently begin AI programs with the use case that looks most strategic in a presentation. They should begin with the work employees already want changed.
Look for a recurring task that consumes time, follows a recognizable process, and still allows a person to review the result. Good early candidates include drafting routine communications, organizing meeting notes, comparing documents, preparing first-pass reports, categorizing requests, or answering questions from an approved knowledge base.
This focus creates a visible win without demanding immediate transformation.
It also supports stronger AI capability building. The World Economic Forum reports that 77 percent of surveyed employers plan to upskill workers in response to AI disruption. Yet generic training often produces knowledge that fades because employees never connect it to actual work.
Building one useful tool forces employees to apply what they learn. They must define the problem, identify the required information, test outputs, recognize failure modes, and decide where human review belongs.
That process develops judgment, not merely familiarity.
Move From Demonstration to Co-Creation
The first tool should usually involve expert support. The critical decision concerns how that support works.
A traditional provider disappears behind the curtain, builds the system, and returns with a finished product. An empowerment-oriented adviser builds in the open. Employees see how instructions get written, how knowledge gets organized, how output gets tested, and how safeguards get added.
The next tool should involve employees more directly. They propose the workflow, help configure the assistant, test realistic scenarios, and refine the results. With each iteration, the adviser does less and the internal team does more.
This graduated model turns users into AI champions. OpenAI’s 2025 enterprise report found rapid growth in the use of configurable GPTs and Projects, including organizations that developed thousands of internal assistants. The significance lies less in the volume than in the pattern: employees increasingly turn useful AI interactions into persistent tools embedded in recurring work.
Champions make that pattern spread. They translate between technical teams and business users, demonstrate credible examples, coach colleagues, and recognize when a proposed use case carries more risk than the team should handle alone.
Give Employees Guardrails Before Giving Them Freedom
Employee-built AI can create serious problems when organizations confuse empowerment with unrestricted access.
Staff should know which information they may enter, which systems they may connect, which tasks require approval, and which outputs demand human review. They also need a clear route for reporting errors or unexpected behavior.
The goal of AI governance should involve enabling responsible action rather than preventing all experimentation. The National Institute of Standards and Technology’s generative AI risk profile gives organizations a structured way to consider risks throughout the design, deployment, use, and evaluation of AI systems.
Leaders can translate that broad framework into practical internal rules:
• Employees may build only within approved platforms and accounts
• Sensitive, confidential, or regulated information requires specified protections
• Every tool must have a named owner
• Teams must test the tool against realistic and adversarial scenarios
• High-impact decisions require human review
• Widely used tools require periodic evaluation and documentation
Organizations also need visibility into what employees build. Microsoft’s current Power Platform governance guidance describes digital guardrails that allow professional and citizen developers to create solutions while administrators maintain security, compliance, and oversight.
The principle applies across platforms. Centralize standards and monitoring while distributing experimentation and problem-solving.
Build a Small Internal System Around the Builders
A sustainable program needs more than a few enthusiastic employees.
Create a small enablement group that includes business champions, IT, security, legal or compliance when relevant, and an executive sponsor. This group should approve platforms, publish simple standards, review higher-risk tools, maintain reusable templates, and help builders solve problems.
Large organizations may call this a Center of Excellence. Smaller organizations can accomplish the same purpose with a monthly review group and a shared library.
The structure should remain light enough to support experimentation. Microsoft’s citizen-development model at Deutsche Bahn combines central standards with local expert teams that coach builders and review solutions before deployment. That model avoids forcing one central team to approve every minor decision while preserving accountability.
The enablement group should also track outcomes. Count fewer things, but choose measures that matter: hours saved, cycle time, errors, rework, employee use, customer response time, and the percentage of tools that remain useful after several months.
The number of tools built means little if employees abandon them.
Recognize Where Employee Building Should Stop
The empowerment approach does not mean employees should build every system.
Professional developers and specialized vendors remain essential when tools involve complex integrations, sensitive data, critical infrastructure, high-stakes decisions, or requirements for extensive reliability and scale. Citizen builders should not quietly construct systems that approve loans, make medical recommendations, determine employment outcomes, or bypass established controls.
Employees should own problem discovery and remain deeply involved in design and testing. Technical experts should own the elements that require specialized engineering and risk management.
The OECD’s workplace research found that worker consultation and training correlate with better outcomes for workers. Consultation does not require handing employees unrestricted authority. It means involving them meaningfully in decisions that reshape their work.
This hybrid model avoids two bad extremes: total vendor dependence and uncontrolled shadow development.
Measure Success by How Much the Organization Learns
The first internally built AI tool may save only a few hours each week. Its larger value comes from what the team learns while creating it.
Employees learn how to describe a workflow precisely. Managers learn where policies contain ambiguity. IT learns which approved capabilities employees actually need. Leaders learn which teams have credible champions. The organization begins building a shared vocabulary for testing, risk, human review, and value.
That learning compounds.
The OECD found that many workers report better performance and greater enjoyment when AI improves their work, while also expressing concerns about privacy, work intensity, and inequality. Leaders should take both findings seriously. Employees will support AI more readily when it removes genuine friction and when they can influence how it enters their work.
That principle sits at the heart of effective AI adoption at work. People support what they help create, especially when leaders give them useful tools, clear boundaries, and visible responsibility.
The strongest AI strategy therefore asks a different question.
Do not ask only, “Which AI system should we buy?”
Ask, “What must our people learn to build, improve, and govern for themselves?”
Vendors can supply technology. Consultants can accelerate the journey. Neither should own your organization’s ability to innovate.
Your long-term advantage will come from employees who understand the work, understand enough about AI to improve it, and possess the authority to turn their knowledge into better ways of operating.
That is capability you own.
Thank you, Dr. Gleb!
The last line is the one to sit with, because capability you own is the only kind that survives a vendor changing their pricing, their roadmap, or their mind. The gate isn’t the tooling anymore, it’s whether your people know what’s on the other side of it, and that’s a question you can start answering this week without a procurement cycle.
His book, The Psychology of AI Adoption at Work: From Resistance to Results, comes out with Georgetown University Press in September 2026.
What’s one thing someone on your team wishes existed but assumes has to be bought? Tell me in the comments, because I’d guess a good number of them are closer than they look.
Questions Leaders Are Asking
Should we build or buy AI tools? Buy the platform, build on top of it. Almost nobody should be building foundation models or core infrastructure. What you build are the configured assistants, workflows, and knowledge layers that sit on a vendor platform and encode how your organization actually works. That’s where the capability lives.
Do employees need to know how to code to build AI tools? No. Most employee-built AI tools are configured, not programmed: instructions, uploaded knowledge, defined steps, and tested outputs inside an approved platform. The skill that matters is describing a workflow precisely and knowing where a human has to check the result. Anything requiring real engineering should go to professionals.
What are the risks of letting employees build their own AI tools? Data exposure, unreviewed outputs reaching customers, tools with no owner when the builder leaves, and quiet duplication of systems IT already runs. Every one of those is manageable with approved platforms, named owners, defined data rules, and human review on high-impact decisions. Set those before you open access, not after.
How do we start an employee AI building program? Pick one recurring task your team already wants to eliminate, build it in the open with expert support so people see how it’s done, then hand more of the next one to them. Add a small review group with IT, security, and a business champion. One useful tool beats a training program nobody applies.
What is a citizen developer? A citizen developer is an employee who builds working applications or automations without being a professional software developer, using approved low-code or AI platforms under an organization’s governance rules. Deutsche Bahn runs roughly 11,000 of them with local expert teams coaching and approving their work before release.
How do we measure whether employee-built AI tools are working? Track hours saved, cycle time, error and rework rates, and how quickly customers get answers. Then track the number that matters most: what percentage of the tools are still being used six months later. Counting tools built tells you about enthusiasm. Counting tools still in use tells you about capability.
About the Author
Dr. Gleb Tsipursky, PhD, is a behavioral scientist called the “Office Whisperer” by The New York Times. He serves as CEO of the future-of-work consultancy Disaster Avoidance Experts, and his academic career includes faculty appointments at Ohio State University and the University of North Carolina at Chapel Hill. His book The Psychology of AI Adoption at Work: From Resistance to Results is out with Georgetown University Press in September 2026.
Joel Salinas is an AI Strategy Coach for founders and leaders, from solopreneurs to teams. AI is everywhere; judgment is scarce. Joel helps leaders adopt AI without outsourcing their judgment to it, through the AI Judgment Workshop and the 90-Day Judgment Engagement. Creator of the AI Leadership Triad. He writes Leadership in Change.
Written by a human, for humans.
The line about the company owning the licenses while the vendor owns the practical knowledge nails why so many AI tools end up half-used within a year. To answer your question directly, on my last team it was an intake assistant to sort inbound requests by urgency, everyone assumed that needed a dev ticket when it was really just a well-tested prompt with a handful of examples attached. Were employees more hesitant to try building something themselves, or more hesitant to admit the fancy vendor tool wasn't actually solving the problem?
Renting always backfires, sooner or later.
Only upskilling your own people allows you to compound