Vibe Coding: Convert Excel apps to web apps. No code required.

Everyone is discussing AI and “vibe coding,” but what exactly are they? At Peerigon, we utilize AI to work more efficiently, and vibe coding is part of our toolbox. In this blog post, we will use a real-life example to demonstrate what can be achieved with it and where its limitations lie. Join us for a vibe coding experiment 🚀

• What is vibe coding? AI writes code based on natural language instructions.
• Is vibe coding an alternative to traditional software development? No! It is an additional tool that you need to know how to use. However, it can be very helpful as a supplement and significantly reduce development time.
• How well does it really work: It works well for prototypes and smaller applications, but has clear limitations
• Our experiment: Excel tool → web app in several iterations
• Conclusion: A helpful tool for certain use cases, but very limited without engineering experience and to be used with caution

Vibe coding was coined in February 2025 by Andrej Karpathy, co-founder of OpenAI and former head of AI at Tesla. His definition from the original tweet from February 3, 2025:

Karpathy describes it as follows: “I build a project or a web app, but it's not really programming — I just see things, say things, do things, and copy things, and it mostly works.”

An interesting comparison is Rick Rubin, the legendary music producer. In a CBS 60 Minutes interview from January 2023, the nine-time Grammy winner said: “I have no technical skills and I know nothing about music.” Nevertheless, he successfully produces hits for artists ranging from Jay-Z to Johnny Cash. He is paid for his taste and communication skills, not for technical know-how.

With all these possibilities, there are also clear limits. It is important to understand that the boundaries are fluid and the decisive difference often lies in the person operating the AI, not in the tool itself.

🎯 Vibe Coding (trust without understanding):

• Complete trust in AI without code review
• “Forget that the code even exists” (Andrej Karpathy)
• Functionality-oriented: The main thing is that it works

⚙️ AI-assisted development (AI as a tool):

• Humans and AI work together
• Code must be explainable and maintainable
• Quality processes remain in place

👨‍💻 Traditional development (manual):

• Code is written entirely by hand
• Classic review and testing processes

The decisive factor: An experienced developer who uses Claude for rapid prototyping is likely to be doing AI-assisted development, even if they say they are doing “vibe coding.” A non-techie who builds a complex app with the same AI is doing real vibe coding—with all the risks that entails.

As Simon Willison aptly puts it: “If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else—that's not vibe coding, it's software development.”

⚠️ Important: Never use your vibe coding product for business-critical purposes without testing it first.

Basically, any modern LLM is suitable for vibe coding. The most important differences lie in user-friendliness and available features.

• OpenAI ChatGPT
• Antropic Claude
• Mistral Le Chat
• Google Gemini

All of these tools have the ability to execute and display code directly. In OpenAI, Mistral, and Google, this is called Canvas, and in Antropic, it is called Artifacts. There are also sharing features to share applications within a team, which vary depending on the type of subscription.

• Lovable: Complete apps through natural language, automatic hosting
• v0: UI components from Vercel, direct deployment
• Bolt.new: Full-stack development, integrated hosting environment

Editors

• Anysphere Cursor: AI-enhanced IDE
• GitHub Copilot: VSCode integration

Terminal tools

• Anthropic Claude Code
• OpenAI Codex
• Google Gemini CLI

Conclusion: Basic LLMs are sufficient for beginners. For serious development → specialized tools, but then it's more like AI-assisted development. Enough of the dry theory. Now let's get started and finally “vibe.”

In our example, we use Antropic Claude, as we have had good experiences with it. Antropic's models (Opus and Sonnett) are well known in the AI dev community as very good coding models. In addition, the results can be published directly via Claude Artifacts and thus shared.

No one likes to do it, but it's necessary: we're talking about estimates. For years, we've been using a small Excel sheet to break projects down into logical chunks that we then estimate as a team.

The logic is straightforward and therefore easy to map in Excel:

• Each task is estimated with a worst case, likely case, and best case.
• The PERT score is calculated as (worst + (likely x 4) + best) / 6.

However, the details are irrelevant for our example.

💡 Pro tip: If you use a super complicated Excel sheet and don't know 100% how it works because it has grown over years in your company, AI can help you explain it.

That's the first prompt. After about two minutes and lots of analysis loops by the AI, the first analysis comes at the end:

🤖 Claude analyzes:

✅ This describes the functionality of the Excel sheet very well.

We extracted the requirements and even received a proposal for the features of the web app:

That sounds good! Now I'd like to see a clickable prototype (without implementing the entire logic):

And just like that, HTML and CSS are generated. Since I didn't specify otherwise, it's classic HTML without frameworks and everything in one file.

It doesn't look bad, and we get immediate feedback on how to proceed:

And now exactly what we often experience in our workshops is happening: Although the requirements seemed very clear in advance, a small idea is turning into something huge. That's not a bad thing, though, as it helps us understand the vision behind the idea and get a clear picture of where the journey could take us.

The following part is particularly interesting:

I would like all of that for our estimation tool, but it makes the project far too complex in its current phase.

🚨 It is important at this point to get on the right track and not let AI build you a jack-of-all-trades (small spoiler: it's not very good at that).

⏪ REWIND: Our initial idea was to convert the Excel sheet into a web application. Topics such as user authentication, team collaboration, charts, and import/export weren't part of the plan before, were they? The Excel sheet was stored somewhere in the cloud as a template and anyone with access could access it. Of course, it would be obvious to tackle these issues in order to create real added value, but that makes the project many times more complex...

Another question arises: Where should the application ultimately run? Is the person writing the prompt able to deploy the application independently and securely?

For anyone who cannot answer “yes” to this question within two seconds, I recommend sticking with a static website and publishing it via Claude Artifacts or ChatGPT Canvas, for example.

That's what we plan to do in this case, so we give the AI the following input:

And Claude doesn't just make a suggestion, it jumps right into implementation.

After a few minutes, we get the first functional version, which we refine bit by bit. The more specific the requirements in the prompt, the better the result usually is. I deliberately kept the wording concise and let myself be guided by the vibe coding style. However, this also means more guesswork and therefore more correction loops.

It doesn't look bad, but there are three problems in the details:

🐛 Unfortunately, the application throws a security error in the browser that has to do with accessing localStorage in the sandbox (Claude Artifacts). If you open the file locally or deliver it via a static web server, you should not get the error.

🏓 But even if you don't know exactly what that means, you can just throw the error back to the AI. That's the beauty of vibe coding ;)

Although the tabs were visible in the click dummy, everything ended up on one page in the first functional version.

The buttons for the actions “Save,” “Load,” etc. are not aligned properly.

With strict vibe coding, you ignore the code that has been created and focus entirely on the prompt. Therefore, we want to fix the errors one by one:

✅ The error message is gone. Tabs and buttons are not fixed yet, but that wasn't our explicit request. So let's move on...

✅ Perfect! The tabs are there and the error message is still gone.

Now let's take a look at the problem with the buttons: On closer inspection, it becomes apparent that the buttons are not only overlapping but are actually not working properly. Classic AI coding experience! In our case, the buttons did not work from the start. But “making things worse” or accidentally “breaking” existing functionality in the course of expanding an application is a very common phenomenon at viben.

The buttons are now neatly arranged in a row and are supposed to work. Unfortunately, they don't in reality, but that's also due to how the application is delivered via Claude Artifacts.

To be fair: These would work in a local environment, and Antropic has since instructed its AI to no longer use these local APIs, as they don't work in the sandbox.

Claude was very confident that the problem had been solved. That's why we want to try another iteration.

You have to give Claude credit for coming up with a very creative solution that works within the limitations of the sandbox. The manual copying method is not elegant, but it is better than no import/export at all.

Finally, we have a working version with a somewhat complicated import/export process. We could spend hours tweaking it, but for our example, we'll leave it at that.

Before we come to our conclusion, let's take a look under the hood.

📊 Facts:

• 918 lines of code in a single HTML file
• ~380 lines of CSS (47.7%)
• ~310 lines of JavaScript (38.9%)
• ~106 lines of HTML (13.3%)
• Zero dependencies - no external dependencies

✅ The good:

• Full feature set with PERT calculations, import/export, and sharing
• Clean, modern UI with responsive design
• Extremely portable—open the HTML file and it works
• PERT calculations are implemented correctly

⚠️ The bad:

• Security vulnerabilities: XSS vulnerabilities due to insecure innerHTML
• Code chaos: Everything in global scope, inline event handlers, no modularization
• No validation: Best case could be bigger than worst case
• Hardcoded assumptions: 8-hour days, 40% buffer
• Maintainability: No tests, no documentation, everything in one file

It is a functional tool that serves its purpose, but suffers from typical ‘proof of concept’ problems: security vulnerabilities, poor code organization, and limited maintainability.

What does this mean for VibeCoding?

This example perfectly illustrates the strengths and weaknesses of VibeCoding:

• Strength: From idea to working prototype in just a few minutes
• Weakness: The code is a classic “it works, but...” example

For internal tools or prototypes, this may be perfectly adequate. For production use with multiple users or sensitive data? Definitely have someone with engineering experience take a look.

We hope this hands-on Vibe Coding example has shown you what the term means. In our example, we used Antropic Claude (desktop) and published the “app” via Artifacts. Vibe Coding also works with ChatGPT and AI tools designed specifically for developers, such as Cursor, GitHub Copilot Agent, and Claude Code.

However, we deliberately limited ourselves to a non-techie setup, as vibe coding is often touted as a replacement for developers. Those with an engineering background can use vibe coding to build and publish much more complex applications. The difficulty here, however, lies in ensuring code quality and security with many, many lines of automatically generated code (which no human would want to review).

✅ Realistic use cases

• Single-user productivity tools:
• 🧮 Personal cost calculators
• 📈 Data analysis tools
• 📊 Personal dashboards
• Data processing:
• 🔄 Format converters
• 🧹 Data cleaning tools
• 📝 Report generators
• Design utilities:
• 🎨 Color palette generators
• ✏️ Typography testers
• 🖼️ Interactive mockups
• Explorative prototyping:
• 🧠 Validate/brainstorm/visualize concepts
• 🎨 Develop UIs for later discussions with UI/UX and dev teams

❌ The limits quickly become apparent

As soon as more than one person needs to use the tool or data needs to be stored, things get complicated:

• 👥 Multi-user applications (shared data required)
• 🔐 Anything with authentication
• 📧 Tools with email delivery
• 💾 Cross-session storage between users

Most “cool” app ideas require servers, databases, or APIs that VibeCoding (without an engineer) cannot provide.

Advanced options: Vibe Coding can certainly create more complex front-end applications, but anything beyond static single-page apps requires special tools, an engineer in the loop, and then it's usually no longer Vibe coding.

Sweet spot: Rapid prototyping and proof-of-concepts, not production-ready code. With engineering tools such as Cursor, Claude Code, or GitHub Copilot, you can get much further than with pure browser Vibe Coding.

The challenge: Ensuring code quality and security with many lines of automatically generated code that no one wants to review.

VibeCoding works best for self-contained applications. As soon as the following components are required, it becomes exponentially more complex:

• 🗄️ Databases (beyond LocalStorage/IndexedDB)
• 🔐 User authentication & session management
• 📧 Email delivery & notifications
• 📤 File upload & server processing
• 👥 Multi-user functions
• 🔌 API integration with error handling

Vibe Coding democratizes app development – but at what price? As with fast fashion, there is a risk of a throwaway mentality.

The “fast apps” problem:

• Code garbage: Thousands of unmaintained single-use apps clog up servers and repositories
• Technical debt: Quick & dirty code that “works for now” but creates problems in the long run
• Security gaps: Unpatched apps with known vulnerabilities become gateways
• Waste of resources: Redundant solutions for problems that have already been solved and high energy consumption through the use of LLMs.

A real-world example: Imagine every department builds its own estimation tool. In the end, you have:

• 10 different versions with similar functionality
• None of them are maintained or updated
• Each has its own security vulnerabilities
• No one knows which version is “the right one” anymore

In addition, LLMs require vast amounts of electricity and water, both during training and operation. If you want to delve deeper into this topic, I recommend the recently published [study by the German Informatics Society]((https://gi.de/meldung/gi-veroeffentlicht-studie-zum-wasserverbrauch-von-ki).

🤔 The problem is not the technology – it's how we use it. Just like with fast fashion, it's about conscious consumption vs. thoughtless production.

✅ Our sustainable principles:

• “Build to learn, not to launch:” Prototypes as learning tools, not end products
• “One tool, well maintained:” Better one well-maintained tool than ten forgotten ones
• “Document or delete:” Code without documentation has an expiration date
• “Security first:” Even prototypes can cause damage

At Peerigon, we use the entire spectrum—but consciously and purposefully:

• Vibe Coding → Concept validation, workshops, experiments (with an expiration date!)
• AI-Assisted Development → Productive apps with an AI boost and professional quality processes
• Traditional Development → Critical systems where every line must be checked

🤝 Pro tip: The perfect handoff

Your prototype is proving itself? AI helps with the next step:

This is how a quick idea becomes a sustainable solution – with the right tool at the right time.

🤖 Statement on the use of AI in this article: This blogpost was written by humans (thanks for the feedback Philipp and Lisa!), including the title, concepts, and code examples. However, we used AI for research and to improve the writing style.