# To Code or Not to Code? Telle est la question. 

**Authors:** Yagiz Yigit
**Categories:** Opinion
**Last Updated:** 2026-03-02T14:26:19.933Z
**Reading Time:** 8 min read

---

## Summary

A philosophical exploration of whether understanding code matters in the age of no-code platforms and AI-assisted development. Does building without coding make you a creator or just an assembler?
Written by Yagiz Yigit, teacher at Albert School and Charles Thepaut, Bachelor student in Madrid.

---



Last week I saw *Hamnet* in Madrid. Shakespeare's famous question, “To be or not to be?”, struck me as surprisingly applicable beyond existence itself. Including this one: **To code or not to code?**

Let me be direct: I am not here to tell you whether you should learn to code. I am here to make you question what we lose, or gain, when we build without knowing how.

## The Ship Sets Sail: No-Code and the MVP

Here is a question for you:

If you replace every plank of a ship with new wood, is it still the same ship?

The ancient Greeks called this the Ship of Theseus paradox. Philosophers have debated it for millennia. No clear answer exists.

Now let me ask you this:

If you build a product using pre-made components, drag-and-drop interfaces, template logic, automated workflows, without writing a single line of code, are you the builder? Or are you the assembler?

This is what no-code platforms offer you: Bubble, Softr, Wix.

They give you the planks. Pre-cut. Pre-treated. Ready to assemble.

You do not need to understand how authentication works to add a login page. You do not need to understand database architecture to store user information. You click, you configure, you launch.

And here is the remarkable part:

**It works. Brilliantly.**

The data speaks clearly: Organizations report up to 90% reduction in development time with no-code platforms (Integrate.io, 2025). You can validate a business idea in days instead of months. You can test your value proposition with real users before investing tens of thousands in custom development.

The MVP, that minimum viable product everyone talks about, becomes actually achievable for the non-technical founder. This is not theory. This is happening right now.

But the Ship of Theseus question lingers, does it not?

You built something. You shaped it. You made decisions about every feature, every flow, every pixel. Yet you did not craft the fundamental components.

Are you the builder? Or are you the assembler?

Does it matter if the ship sails?

## The Hybrid Harbor: Vibe Coding and Quick Functionality

Let me introduce you to the middle ground: AI-assisted coding, prompt-driven development, vibe coding.

You describe what you want. The AI writes the code. You review, you adjust, you deploy.

Take Replit or any of the new AI coding tools. You need a custom feature your no-code platform cannot handle, perhaps a specific data visualization or a unique user interaction.

You prompt:

> Create a dashboard that shows user engagement over time with filterable date ranges.

The AI generates the code. You tweak the styling, adjust the logic, make it yours.

Or do you?

The numbers are striking:

- 41% of all code written in 2025 is AI-generated (Index.dev, 2025).
- 84% of developers use or plan to use AI in their development process (Index.dev, 2025).

This is not experimental anymore. This is mainstream.

Here is what happened:

You got working code. Perhaps you understand parts of it. Perhaps you do not. But you can modify it through conversation with the AI. You can iterate without truly comprehending the underlying architecture.

You are replacing more planks on the ship, but this time, you are watching them being carved, even if you are not wielding the chisel yourself.

This is powerful for quick functionalities.

Need a simple integration? Vibe code it.  
Want to prototype a feature before committing to full development? Vibe code it.

The speed is intoxicating. The accessibility is democratizing.

## A First-Hand Perspective  
### By Charles Thepaut, a first-year bachelor's student based in Madrid

I have felt the seduction of vibe coding firsthand.

There is something almost unreal about describing an idea in plain language and watching working code appear seconds later. The first time I built a small dashboard this way, I remember thinking that this felt unfair, as if I had skipped years of apprenticeship.

I did not wrestle with syntax. I did not read documentation for hours. I just described what I wanted, and it materialized. It felt like creation without friction.

And yet, that ease quickly turned into quiet anxiety. The code worked, but I did not fully understand why it worked.

The moment that unsettled me most came when it stopped working.

I had asked the AI to build a simple user authentication flow for a small project. It generated everything: routes, validation, token handling. It looked clean. Structured. Professional.

I deployed it confidently.

Then users started getting a vague server error when trying to log in.

I opened the code and realized I did not actually understand how the token logic was structured. I could read it, but reading is not the same as grasping.

I tried prompting the AI to fix it, copying error messages back and forth. It suggested changes, I applied them, the error persisted.

I was stuck in a loop of adjustments without comprehension.

What frustrated me was not just the bug. It was the realization that I did not know how to debug it myself. I did not know where to place logs strategically. I did not fully understand the lifecycle of the request.

I was depending on the same system that wrote the code to also rescue me from it.

In that moment, I wondered whether I was actually building something or just orchestrating outputs.

Was I learning to think like a developer, or simply learning to prompt more precisely?

That experience did not make me reject vibe coding. It made me more cautious.

I still use it. The speed is undeniable.

But now I hesitate before trusting code that looks correct. Because sometimes it is correct. And sometimes it is only convincing.

And if I cannot tell the difference, I have to ask myself again:

Does understanding matter if the feature still works, until the day it doesn’t?

## One Must Imagine the Coder Happy

Picture the traditional path of the craftsperson. The apprentice, or in the French context, the alternant. Years spent learning fundamentals. Understanding materials. Making mistakes.

The master woodworker who spent a decade learning grain patterns before crafting their first chair. The master chef who spent years on basic knife skills before creating their signature dish.

The struggle was not incidental. It was essential.

The journey taught them not just how to make things, but how to think about making things. How to see problems. How to understand when something is right or wrong and why.

Now picture this:

What if you could create masterwork-quality output on day one?

No apprenticeship. No years of fundamentals. Just results.

Are you a master? Or are you someone with a powerful tool?

This is the question no-code and AI-assisted development force us to confront.

We can build sophisticated applications without understanding authentication protocols. We can deploy machine learning models without grasping the mathematics. We can create beautiful interfaces without knowing how browsers render CSS.

The ancient Greeks told the story of Sisyphus, condemned to roll a boulder up a hill for eternity, only to watch it roll back down, then push it up again.

Absurd. Endless. Meaningless.

But Albert Camus saw something different. In *The Myth of Sisyphus* (1942), he argued we must imagine Sisyphus happy. Because the struggle itself creates meaning. The act of pushing, not reaching the top, is where we find purpose.

Traditional coding is Sisyphean, is it not?

You learn a framework. It becomes obsolete.  
You debug for hours. New bugs appear.  
You master a programming language. A new one emerges.

The boulder rolls down. You push it up again.

No-code removes the boulder entirely.

Or does it just give you a different boulder?

Perhaps the struggle shifts from “how do I make this work?” to “what should I make?” From technical challenge to strategic challenge. From implementation to vision.

But here is what haunts me:

Does removing the technical struggle remove something essential?

When you do not get your hands dirty with code, when you do not spend nights debugging, when you do not battle with documentation, do you lose an understanding that cannot be gained any other way?

## Telle est la question

So let me return to where we started:

**To code or not to code?**

I will not give you an answer. That would be dishonest. Because the answer depends on what you are trying to build and who you are trying to become.

No-code gets your MVP to market. It validates your ideas. It democratizes creation. These are not small things. They are revolutionary.

Vibe coding gives you functionality without the years of apprenticeship. It accelerates execution. It removes barriers.

But here is the question I leave you with:

When creation becomes frictionless, when we can shape outcomes without understanding mechanisms, when we build ships without crafting the individual planks, what do we gain and what do we lose?

Maybe we gain time. Maybe we gain accessibility. Maybe we free ourselves to focus on vision rather than execution, on strategy rather than syntax.

Maybe this is the future we should embrace.

Or maybe there is wisdom in the struggle.

Maybe understanding how things work, really work, at a fundamental level, gives us something beyond the ability to make them.

Maybe the journey of the alternant teaches us to see patterns we would otherwise miss.

Maybe Sisyphus is actually happy because of the boulder.

Maybe.

The ship sails regardless of whether we understand how planks become vessels. The code executes whether we comprehend the algorithms.

But one question remains, and it is yours to answer:

Who is the real creator? The one who understands how, or the one who knows what and why?

Telle est la question.

## About the Author

This article was written by **Yagiz Yigit**, Marketing Automation & No-code teacher at Albert School.

The section *“The Hybrid Harbor”* was co-written with Charles, a first-year student at Albert School. His firsthand experience with vibe coding brought a concrete and lived perspective to that part of the article.

## References

Camus, A. (1942). *The Myth of Sisyphus*. Gallimard.

Index.dev. (2025). *Developer Productivity Statistics with AI Tools 2025*. Retrieved from https://www.index.dev/blog/developer-productivity-statistics-with-ai-tools

Integrate.io. (2025). *No-Code Transformations Usage Trends: 45 Statistics Every Business Leader Should Know in 2026*. Retrieved from https://www.integrate.io/blog/no-code-transformations-usage-trends/

## Key Takeaways

1. No-code platforms can reduce development time by up to 90% but raise questions about true ownership of creation
2. AI-generated code now accounts for 41% of all code written, fundamentally changing the developer experience
3. Understanding underlying systems becomes crucial when debugging and maintaining AI-generated solutions
4. The shift from technical implementation to strategic vision may represent a new form of valuable expertise
5. Traditional coding struggles may be essential for developing problem-solving intuition and technical judgment

## Frequently Asked Questions

### What are the main benefits of no-code platforms?

No-code platforms offer up to 90% reduction in development time, enable rapid MVP validation, and make product building accessible to non-technical founders without requiring programming knowledge.

### What is 'vibe coding' and how does it work?

Vibe coding refers to AI-assisted development where you describe what you want in plain language, and AI generates the code. You can then review, adjust, and deploy without writing code from scratch.

### What are the risks of relying on AI-generated code?

The main risks include difficulty debugging when things break, lack of understanding of underlying architecture, and dependency on AI systems to fix problems you can't diagnose yourself.

### Does understanding code still matter in the age of no-code?

Yes, understanding fundamentals becomes crucial for debugging, making informed architectural decisions, and maintaining systems long-term, even when using no-code or AI-assisted tools.


---

*Article from [Albert's Deep Dive](https://deepdive.albertschool.com) - Albert School's Journal*