Three months ago, we set an ambitious target: train 1,000 people in AI-assisted development by the end of the year.
We hit that milestone in just over 100 days. Many have already deployed live solutions. Some are generating revenue. Some are fundraising. Others are transforming how their organisations operate.
But the most revealing outcome wasn't the number of people trained or products built. It was what emerged when we spoke to organisations about how they approach AI capability.
The conversations followed a pattern.
Us: "Who in your organisation understands your constraints best?" Them: "Our team, obviously."
Us: "Who knows which problems are actually worth solving?" Them: "Our people who live these challenges daily."
Us: "So why aren't they the ones building your AI solutions?" Them: Long pause.
This is where most organisations get it wrong. They're buying execution when they should be building expertise.
The Capability Gap Nobody Talks About
I have nothing against consultants. We work with excellent ones. But here's the structural problem: when consultants leave, the capability leaves with them.
You get a solution. Maybe it works, maybe it doesn't. What you don't get is the ability to iterate when requirements change next month. Or the understanding to identify the next opportunity. Or the confidence to question whether the solution is actually optimal for your context.
You're left dependent. Again.
The alternative isn't revolutionary. It's obvious. Yet most organisations miss it entirely.
The people who should be building your AI solutions already work for you.
Not all of them. Not for every solution. But far more than you think.
What We Learned from 1,000 People
When we started NoCodeLab.ai, I expected certain patterns. Technical backgrounds would progress faster. Younger participants would adapt quicker. People from tech-adjacent industries would have inherent advantages.
I was wrong on all counts.
The strongest predictor of success wasn't technical background, age, or industry. It was proximity to real problems.
The solopreneur building a solution for their own business moved faster than the corporate hire attending because their manager thought it would be useful. The operations manager tired of manual processes outperformed the innovation team member exploring "what's possible with AI."
Why? Because when you're solving your own problem, you know instantly whether your solution works. You don't need stakeholder validation or approval cycles. You build, you test, you iterate. The feedback loop is immediate.
This matters for organisations trying to build AI capability. Your best candidates aren't the people who volunteered for the innovation working group. They're the people who spend Friday afternoons building elaborate Excel macros because the approved tools don't solve their actual problems.
Find those people. Give them better tools. Get out of their way.
The Embedded Expertise Model
Here's what permanent internal expertise looks like in practice:
Consultants: Build you a customer service chatbot. It works. They leave. Six months later, your product changes. The chatbot gives outdated information. You call the consultants back. They charge you again.
Embedded expertise: Someone on your team builds the chatbot. Product changes. They update it in an afternoon. They see another department struggling with similar issues. They build them a solution. They train three colleagues. Capability compounds.
This isn't theoretical. We've watched it happen across the board in the past 100 days.
Take a Managing Director at a leading advertising agency in the UAE. He wanted to upskill his team to prototype AI solutions internally. Traditional AI training programmes weren't landing: too theoretical, not enough immediate practical value.
We ran a single practical masterclass focussed on building, not theory.
By the end of the session, his team had generated over 70 Product Requirements Documents. These are 70 ideas they could now actually build themselves. This wasn't just training. It was an IP-building exercise that created tangible business value.
But the real transformation wasn't the PRDs. It was what happened to the people.
The team became re-energised. They saw AI not as something to learn about in abstract terms, but as an ally that could accelerate their work, streamline their workflows, make them more efficient and—critically—happier in their jobs.
That happiness factor is massively underrated. When people can build solutions to their own frustrations rather than wait for someone else to maybe fix it someday, the psychological shift creates momentum that compounds.
This is what embedded expertise looks like in practice. Not consultants building something and leaving. Internal teams discovering they can solve their own problems, then solving more problems, then teaching colleagues. Capability that multiplies.
What "Embedded Expertise" Actually Requires
Building internal AI capability isn't about sending people to a workshop and hoping they'll figure it out. Three conditions must exist:
1. Permission to Build (Not Just Learn)
Most training programmes teach theory. Participants learn concepts, complete exercises, receive certificates. Then they return to their actual jobs where they're not empowered to implement anything they learned.
This is why completion rates matter less than deployment rates. We don't measure success by how many people finish our programme. We measure it by how many people build something they need to excel in their jobs.
Your organisation needs to explicitly permit people to build and test solutions. Not as side projects hidden from management. As legitimate work.
2. Protection from Production Governance
Traditional software development involves specifications, approval chains, QA cycles, and deployment processes designed to prevent failure. These exist for good reason in production systems.
But you should use them differently. Experiment in-house with rapid prototyping. Build rough versions. Test with real users. Learn what actually works. Then involve software development teams when you're ready to ship something that needs to scale, needs security hardening, or needs to integrate with critical systems.
The entire point of AI-assisted no-code development is rapid prototyping. Build something rough. Test it with three users. Learn. Iterate. The first version is supposed to be imperfect.
If your organisation requires every internal tool to go through the same governance as customer-facing systems, you'll never build internal capability. You'll just slow down developers and dampen innovation.
3. Tolerance for the Adjacent Possible
The solutions people build won't always align with the problems leadership identified.
Someone attends training to build a customer onboarding workflow. They realise the real problem is how product information flows between departments. So they build that instead.
This isn't scope creep. It's the whole point. The people closest to work understand which problems actually matter. Your job is to enable them to solve those problems, not to prescribe solutions for problems you identified from three levels up.
When You Still Need External Expertise
Embedded capability doesn't replace all external support. It redefines when external expertise makes sense.
You need external specialists for:
Architecture decisions that require deep technical expertise
Security implementations that can't tolerate mistakes
Complex integrations with critical systems
Knowledge transfer when you're entering entirely new domains
You don't need external specialists for:
Prototyping potential solutions before committing resources
Building internal tools that serve fewer than 100 users
Testing whether AI can solve a particular workflow problem
Iterating on solutions as requirements evolve
The distinction matters: external expertise for specialised knowledge and high-stakes implementation. Internal teams for exploration, iteration, and solutions that need to evolve with your business.
The AI Champions Model
This is why we're launching the AI Champions certification programme in 2026. Not because we think everyone needs certified experts, but because we've learned that capability spreads through champions, not training volumes.
One person gets genuinely capable. They build something that matters. Three colleagues notice. They want to do the same. The original person teaches them. Capability compounds.
This is how organisations actually transform. Not through enterprise-wide training initiatives. Through small groups of internal experts who prove what's possible, then multiply.
We're targeting 100 certified champions across Q1-Q2 2026. Not 10,000. Because 100 internal experts who each enable 10 colleagues creates more lasting change than 10,000 people who attend a workshop and never deploy anything.
Here's What You Need To Do in 2026
The technology landscape has shifted. AI-assisted development tools have reached a capability threshold where non-technical professionals can build real solutions to real problems. The constraint on innovation is increasingly not talent or intellect, but access to the frameworks and tools that unlock them.
If you're serious about building AI capability that lasts beyond any single project or engagement, here's where to allocate budget in 2026:
1. Identify Your Internal Champions (Q1 Priority)
Don't start with enterprise-wide training. Start with 5-10 people who:
Are already building workarounds (Excel macros, manual processes, shadow IT)
Understand real operational problems, not theoretical opportunities
Have influence across departments
Want to build, not just attend workshops
Budget allocation: Internal time + small pilot programme investment
2. Give Them Permission To Experiment (Immediate)
Create explicit space for rapid prototyping that doesn't go through production system governance. This isn't about lowering standards—it's about separating experimentation from deployment.
Budget allocation: Minimal. This is policy, not spend.
3. Invest In Build-Focussed Training, Not Theory (Q1-Q2)
Skip the "Introduction to AI" workshops. Invest in programmes where people build actual solutions during training. Measure success by deployment rates, not completion certificates.
Budget allocation: Practical training programmes that focus on building real solutions.
4. Create Internal Capability Programmes (Q2-Q3)
Once you've identified champions, certify them to lead AI adoption internally. These become your permanent capability multipliers—people who can train colleagues, validate use cases, and drive continuous innovation.
Budget allocation: AI Champions certification programmes (100 participants across Q1-Q2 2026 generates organisation-wide impact)
5. Partner With Development Teams For Production (Ongoing)
When prototypes prove valuable, involve software development teams for security hardening, scaling, and integration with critical systems. This is where traditional development expertise adds maximum value.
Budget allocation: Shift from "build everything externally" to "validate internally, production-ise strategically"
The Budget Reallocation Question
Boston Consulting Group's 2024 AI Radar survey of 1,400+ C-suite executives revealed a striking gap: 89% rank AI as a top-three priority, yet only 6% have begun upskilling meaningfully.
Why this matters: Companies that upskill systematically are 1.5 times more likely to achieve cost savings exceeding 10%. The technology delivers results—but only when people know how to use it.
That 83-percentage-point gap between intention and action is where competitive advantage will be won or lost in 2026. Organisations that close it will compound capability with every iteration. Those that don't will still be hiring consultants to solve the same problems in 2027.
The shift required: Stop treating training as an afterthought. Start treating internal capability building as the primary investment, with technology and external expertise as enablers.
The Question for 2026
The traditional divide between "technical" and "non-technical" professionals is collapsing faster than most organisations realise. AI-assisted development tools have reached a capability threshold where people can build real solutions to real problems. Not toy projects. Not prototypes that require developers to make them production-ready. Actual deployed solutions that people use.
This changes the equation for how organisations build technical capability.
The consulting model made sense when building software required specialised technical expertise that took years to develop. You needed external experts because internal capability took too long to build.
That constraint is weakening.
The question for your organisation isn't whether AI tools work. They do. The question is whether you're building the internal capability to use them, or whether you're outsourcing that capability to people who don't understand your context.
The people who should be building your AI solutions already work for you. They understand your context, your constraints, your actual problems.
The question isn't whether they can. It's whether you're enabling them to.
Are you building expertise that compounds, or buying execution that evaporates?
That's the decision that will define competitive advantage in 2026.
What's Next
If you're serious about building AI capability that lasts, our AI Champions certification programme launches in Q1 2026.
What's your organisation's approach to building AI capability? Where are you allocating budget in 2026? Share your strategy in the comments.
Sara Simeone Founder, NoCodeLab.ai - Email team@nocodelab.ai for more information.
Source: Boston Consulting Group, "BCG AI Radar: From Potential to Profit with GenAI," January 2024, based on survey of 1,406 C-suite executives across 50 markets.