Vibe Coding for Enterprise Upskilling & Enablement - The Conversation We're Not Having
Image by Pixabay

Vibe Coding for Enterprise Upskilling & Enablement - The Conversation We're Not Having

"I very frequently get the question: 'What's going to change in the next 10 years?' And that is a very interesting question; it's a very common one. I almost never get the question: 'What's not going to change in the next 10 years?' And I submit to you that that second question is actually the more important of the two; because you can build a business strategy around the things that are stable in time." — Jeff Bezos

Looking back at the last two decades, we've seen the emergence of cloud computing (starting 2006), an explosion of data into big data (Peak Hype: 2012-2016), and multiple waves of AI hype—from Machine Learning (2006-2012), Deep Learning (2012-2018), Generative AI (2022-present).

In parallel, we've witnessed the "Learn to Code" movement (2013-2016), the "Hour of Code" launched by Code.org backed by Microsoft, Google, and Facebook, aimed to introduce millions of students to programming. With the recent emergence of agentic coding, programming has lost its appeal as a near-safe path to a successful career in tech. Vibe Coding became the new kid on the block, both admired by freelancers, startups, and feared by Senior Developers, and DevOps Engineers in the enterprise.

"There's a new kind of coding I call 'vibe coding,' where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." — Andrej Karpathy, February 2, 2025

This pattern of making programming more accessible through natural language isn't new.

English has been the hottest programming language before—over and over again:

  • 1959 – COBOL (Common Business-Oriented Language): Designed for business data processing, with syntax resembling English. Example: ADD TAX TO TOTAL GIVING FINAL-AMOUNT
  • 1974 – SQL (Structured Query Language): Declarative language for querying databases. Example: SELECT name FROM employees WHERE department = 'Sales';
  • 1988 – Wolfram: Natural language mathematical computing
  • 2000s – No-Code & Low-Code platforms like Mendix, Microsoft Power Platform, and OutSystems
  • 2022 – Prompt Engineering
  • 2025 – Spec Coding

Reflecting on Bezos's insight about what doesn't change:

Putting business users closer to technology capabilities has been a consistent trend for over half a century

No company will ever ask to move their business users further away from IT—the evidence shows the opposite direction is inevitable.

What's different now is the acceleration. We have no precedent in history for the current pace of technological advancement. This isn't just about upskilling anymore—it's about preventing entire business functions from drifting too far from the technology edge. The risk isn't just skill gaps; it's organizational obsolescence.

The Startup Noise Is Drowning Out the Real Opportunity

The current vibe coding conversation is messy. We're mixing up startup chaos with enterprise reality. Yes, Lovable raised $200 million. Yes, there are horror stories about accidental database deletions and security breaches. But none of these startup risks apply to mature enterprises.

Enterprise IT doesn't let business users push random applications to production. That's not how this works.

So while everyone's arguing about risks that don't exist in our context, we're missing the actual opportunity sitting right in front of us.

There's already consensus in enterprise IT: vibe coding is a good fit for prototyping. This might seem obvious, but it's actually quite significant. Many established, conservative enterprises in pharma, insurance, banking, automotive struggle with exactly that—expressing ideas as prototypes and learning while building them. For business users in these non-digital-native environments, vibe coding as prototyping represents a massive cultural shift.

The challenge isn't technical departments using these tools—many already are. The opportunity is that vibe coding hasn't spilled over to business users yet.

Traditional Learning Is Quietly Collapsing

Let's be honest about what's happening to corporate upskilling. The instructor-led training and MOOC (Massive Open Online Course) model borrowed from edX, Coursera, Udacity, Khan Academy just isn't sufficient for modern learning. Learning & Development teams face resource constraints. Content has shorter shelf life than ever. One-size-fits-all programs deliver questionable value.

What I'm seeing is a fundamental mismatch: we're trying to teach building skills without actually building anything.

Vibe Coding as Learning Infrastructure

Here's the hypothesis I'm testing with current clients: What if we treated vibe coding platforms as learning infrastructure? Let me walk you through practical examples—primed for pharmaceuticals but easily adjusted to other industries.

The approach uses publicly available data and consumer tools initially. No internal company data needed, no access to core systems required. This creates a safe learning sandbox while companies evaluate whether tools merit enterprise investment.

Build a website dedicated to vaccine history. Tools like Lovable, Bolt, or V0 let users build websites quickly while learning UX, information architecture. One interesting observation: once users learn to build with these tools, they don't want to go back to PowerPoint. It's also a practical lesson in vibe coding limitations—"Why is the background yellow when I specifically wanted green?"

Tell the story of world population growth with Google Colab. This Jupyter Notebook distribution lets users leverage Python's rich ecosystem for data manipulation and visualization—even with no prior programming experience. While Excel remains unparalleled in business user adoption, discovering Python's capabilities becomes a game changer for analytical roles. Users also learn about framework maturity—some Python libraries are solid, others are new, buggy, and don't work well. It's valuable for business users to discover that viral social media frameworks often fall short in real-world testing.

Build a chatbot for oncology research questions. Platforms like Vapi enable voice agents within minutes. Automation platforms like n8n come with steeper learning curves but offer nodes for various tasks—fetching data, database operations, Google Spreadsheet integration, and leveraging various LLMs with RAG (Retrieval Augmented Generation) using publicly available clinical studies.

Jump into production-grade environments. Some business users develop an appetite for actual programming. Google Cloud Platform is surprisingly accessible to non-developers thanks to Gemini Code Assist. They can build applications using various LLMs, containerize, and deploy to endpoints. This emulates real-world software development—writing and deploying in small increments, where failures become lessons, one small step at a time. Business users report getting excited about this because they're natural problem solvers—a skill they never thought to apply to coding because it wasn't accessible before.

The tool ecosystem is enormous, and business users quickly find their preferred environments.

Why Consumer Tools First

Current technology waves are driven by consumer tools. Many are open source or open code—meaning tools like Lovable or n8n can be deployed "On-Prem" (self-hosted) for added security, privacy, and cost control.

The "try before you buy" rationale: companies avoid pitfalls of investing in underutilized technology. While consumer Lovable is cheap and easy to deploy, its enterprise equivalent Superblocks with Databricks integration represents significant investment. The progression makes sense: "We tried Lovable, discovered multiple enterprise use cases, now we want to build and deploy in production."

Some companies are already using consumer tools like Lovable in production—while others switch to the enterprise grade UI builders like Superblocks. This requires careful evaluation: Is the tool good for testing specific technology capacity (like building UIs through natural language)? Does it hold potential for internal deployment? What are the constraints? Each tool needs individual assessment based on intended use and organizational risk tolerance.

Cultural Shift

These examples might seem simple, but they create profound cultural impact. We're building safe sandboxes for failure at microscopic scale. Instead of big, risky transformation initiatives that fail spectacularly, we enable continuous, small-scale learning that compounds over time.

Consider what happens when a marketing manager uses natural language prompts to build a simple dashboard. They start understanding API limitations through direct experience. They encounter data quality issues firsthand—discovering why that customer database has inconsistent entries, or why certain metrics don't align across systems. Most importantly, they begin to grasp why IT asks so many detailed questions about requirements. What once seemed like bureaucratic gatekeeping now makes perfect sense.

Business users organically start applying DevOps thinking: version control, testing, documentation. Not because we trained them on DevOps principles through formal courses, but because they needed these practices to make their small projects actually work. When their chatbot breaks after they modify a prompt, they learn the value of keeping previous versions. When their dashboard shows wrong numbers, they discover the importance of testing data sources.

They begin to understand complex concepts such as MCP (Model Context Protocol) on a code level, not just as theoretical frameworks discussed in meetings. This hands-on comprehension creates a foundation for meaningful technical discussions.

This isn't about replacing IT or turning business users into developers. It's about creating informed conversations between business and technology teams. When both sides understand the practical constraints and possibilities, collaboration becomes exponentially more effective.

The Questions Worth Asking

This is emerging territory. We don't have five years of ROI data or massive case studies. What we have is a shifting landscape and early signals from organizations willing to experiment in an era of unprecedented technological acceleration.

Questions I'm wrestling with:

  • How do we bootstrap experimentation culture in risk-averse environments?
  • What governance frameworks work when applications never leave internal networks?
  • How do we measure learning outcomes rather than just application outputs?
  • Which business functions are most ready for this approach?
  • How do we balance moving fast with uncertainty while minimizing risks without crippling the organization?

An Invitation to Explore

I'm not claiming this is the ultimate solution to enterprise upskilling challenges. I'm sharing early experiences and proposing it's worth exploring for organizations that embrace cloud-first thinking and understand experimentation value.

Currently working with select pharmaceutical clients to understand what works, what doesn't, and how to scale promising approaches. The patterns are still emerging.

This is the reality every company needs to prepare for—moving with high uncertainty while building strong hypothesis-testing capabilities. If you're seeing similar opportunities in your organization, or if you're skeptical about whether this translates to your organization, let's continue this conversation. The enterprise vibe coding playbook is still being written.

Jack Lampka, MBA

27 years in data & AI ➡️ KEYNOTES & ADVICE ➡️ Demystifying AI for healthcare ➡️ Helping companies navigate through the hype ➡️ 🇺🇸 🇩🇪

2mo

Hi Rafael Knuth. Yes, using LLMs to create software code, i.e., vibe coding, is a good fit for prototyping. Software developers know that and are more productive. But they also realize the errors that vibe coded software generates and are able to fix it. What happens if you let non-coders vibe code? You also get erroneous software, but these non-coders won't know it. Having business users create vibe code and then developers fix it, is not a practical approach. This is the challenge with vibe coding: it's good for developers and misleadingly good for business users. Using LLMs to engage with data, i.e., Generative BI, is a great approach that is now being implemented by many companies. But data experts develop these applications, not business users. BTW, the historical overview of the "natural" programming languages is insightful. And, if vibe coding platforms become a learning infrastructure, I'm all for it. Just don't expect software developers to fix vibe code generated by business users.

Kirill Ezhemenskii

Senior Frontend Developer | React Native | Mobile Apps | Technical Lead

2mo

So far, I see a voluntary combined contribution of each participant to the process of developing the experiment. Each person, to the extent of their aspirations and limitations of access to data, tries to use a convenient tool for solving urgent problems. Sets of such tools are formed into hierarchical structures corresponding to current roles and are integrated at higher levels. Gradually, such a zoo evolves into a kind of corporate tool network. At the same time, governance frameworks are also manifested or approved. The time savings obtained from the use of such tools seem to generously cover the costs of their implementation. Sensitive data does not leave the company, because it is processed by tools deployed on their resources, and access to them is carried out in accordance with roles, as before. From my observations, this entire process looks controlled and does not cause obvious risks. Let's continue to observe, participate and share knowledge.

Like
Reply
Kirill Ezhemenskii

Senior Frontend Developer | React Native | Mobile Apps | Technical Lead

2mo

The questions raised in this article closely intersect with my research. Thanks to Rafael Knuth for raising this topic. I have long observed such a pattern as learning from one's mistakes among software developers. The symbiosis of the developer and AI in solving a problem leads to a sharp acceleration of human learning, incomparable with any courses and books. Managers can now dive deeper into development areas, and engineers in the business area. Attempts to practically deploy such unfinished tools as MCP and Agents in a closed environment now lead to an avalanche of insights for teams. Perhaps this is not always good when a person ignores all the possibilities of a language, framework, library or service, and focuses heavily on a narrow area of a specifically solved problem. However, this leads to a fantastically fast result.

Like
Reply

To view or add a comment, sign in

Others also viewed

Explore content categories