Since I've become involved in AI, my queries (prompts) have become increasingly specific. I hear more and more people posting about NoCode, claiming that AI is replacing developers and putting thousands of people out of work.
Lacking the perspective to say for sure if it's accurate, I decided to form my own opinion. With several decades of coding experience (C, C#), I set myself the goal of developing a small app in an unfamiliar environment. The aim is to control the AI so that it does all the coding work without me writing a single line of code.
So I embarked on the adventure… without writing a single line of code.
To meet all my criteria, I chose a small web application with a fun HTML viewer. I'm in the simplest environment I know:
- Windows environment
- An internet browser
- A connection to AI via chat.
And so the iterative process becomes:
- I give the AI a directive via the chat
- She sent me a zipped file containing all the HTML code for the application.
- I unzip
- I launch the file in the root directory index.html
- I visualize the result
- I analyze the application's behavior
- I am giving a new directive
Thus, by controlling an AI in the browser, iteration after iteration, I managed to obtain a small, stable graphical viewer (zoom, navigation, mini-map, capture…).
On paper, it's the expected promise: "AI codes, so I can create quickly." In practice, I invested about 60 hours for a first functional level. And this timeframe makes sense once you understand where the time goes: the complexity doesn't disappear, it shifts. You don't code... you design, you test, you debug, you version, you make decisions.
What I learned (and didn't initially suspect)
- The difficulty is not the code, it's the precision.
An AI executes. It doesn't guess. If your request is vague, it "fills in the gaps" in its own way. The result may be coherent… but not the one you had in mind. I discovered a persistent gap between the imagined interface and the actual interface. A large part of the iterations stems from this.
- Design errors... often come from the designer.
When you're not an expert, you sometimes choose a bad interface from the start: too many buttons, poor placement, poorly structured panels. Then you "hack" things together instead of establishing clear rules. A classic example: a panel that should have a fixed header and a scrolling area... but this isn't specified. The result: everything scrolls, the "close" button disappears, and you go around in circles. I've learned to formulate simple constraints: "fixed header," "only one X button," "no overflow," "scrolling only applies to the content.".
- The real driving force behind the project is the iterative loop.
Function design → AI implementation → testing → bugs → fixes → (sometimes) redesign → stabilization. A function isn't "done" when it first appears; it's done when it remains stable after three more iterations. And yes: sometimes, it wasn't a bug... but a bad initial idea.
- Without version control discipline, you lose control.
The rule that saved me: 1 release = 1 tested version. If a fix breaks something else (regression), I revert to the last stable version. Otherwise, you end up with the dreaded "it worked yesterday" without knowing why. I also kept a mini changelog (3 lines per version): what changed, what's stable, what's still fragile.
- Developing via AI in the browser has its own constraints.
As the thread grows (text, images, code), the browser can slow down, freeze, or make the session frustrating. Yes, I've sometimes had to switch threads to regain a smooth interface. The solution: externalize the project's "foundation" (rules, invariants, reference version, changelog) to start fresh without having to explain everything again.
- To move forward, we must both hold the reins of AI and not get discouraged.
This is undoubtedly the most difficult part of the exercise. The human factor is paramount in the overall iteration process. Perseverance is key, as is the ability to negotiate with the AI when faced with a roadblock, and a willingness to question one's assumptions.
What I hadn't anticipated: the "minimum technical level"«
Even without coding, you learn concepts: testing on different screen sizes, understanding that a browser can block certain functions in local file mode, knowing how to restart properly, organizing folders, and above all, describing a problem as a scenario (“I click here → this happens → I expect this”). It's a transferable skill: it's similar to recipe/quality testing.
Who can invest 60 hours?
If your need is urgent, this isn't the most cost-effective approach. However, if you're looking for autonomy, skills development, or a prototype, it's very educational. The real benefit, for me, is having confirmed what I know about the entire software product development chain: design, trade-offs, iterations, stability, and robustness. It dispels the illusion that "an app is just a screen with buttons.".
What I would do again (and what I would avoid)
✅ I would do it again:
• One request = one measurable objective.
• Always specify: context → objective → constraints → test.
• One function at a time, then stabilization.
• Written invariants (“do not touch…”, “the header remains fixed”, etc.).
• Systematic versioning + mini changelog.
❌ I would avoid:
• “Improve everything” requests (this triggers redesigns and regressions).
• Global refactorings too early.
• Add new features as long as a critical bug is not fixed.
Conclusion of my feedback:
Creating a "no-code" application is possible... but it's not free. AI accelerates code production; it doesn't automatically accelerate clarity, design, and validation. The real skill here is piloting: observing, deciding, constraining, testing.
I've written a comprehensive article on how to create a no-code app. I'd like to share it with you. Just leave a comment with "PDF" and I'll send you the download link to my study on "creating a no-code app".
If you are considering this path, I would be happy to discuss: what type of tool do you want to create, and what would be your first minimum viable product (MVP) feature?
#IA #Productivity #NoCode #Devolution #UX #PromptEngineering #ReturnDExperience
