So many talk about vibe coding and its negative effects or error-prone designs. I got tired of it and felt I should make one more post. 🙂
There’s been a growing debate in tech about AI-assisted coding and whether people who use it truly “understand” what they’re building.
From my experience building real offline-first apps, I think this debate is based on an outdated assumption — that you must understand every line of code to be a real builder. 🤔
Building Has Changed
- I started building apps by describing what I wanted, not by writing code.
- “A Gasap retailers webapp to track daily gas sales ”
- “An offline reader”
- “A simple system that stores and retrieves data in the browser”
AI generates the implementation. I test behavior in real usage. Over time, the focus shifted from syntax to:
- system behavior
- real-world usefulness
- whether it solves the problem 🙂
The real skill is not writing code; it is:
Clearly describing intent and recognizing when the system does not match it.
If something breaks, I don’t need to understand every line of code to describe the symptom and get it fixed.
What Has Changed
AI has not removed engineering. It has removed manual construction.
The effort has shifted to:
- defining what should exist
- validating what was generated
- iterating until behavior matches intent
Personal Context
My long use of Windows XP and Windows 7 eventually birthed the idea of Gnokestation — making the vibe engineering process feel less like a headache.
Imagine building and coding an entire operating system from an Android phone. That experience pushed me further into thinking that the bottleneck is no longer syntax, but execution clarity and system design.
In the same direction, I’ve replaced most of my Play Store apps with Gnoke Apps, and I’m genuinely satisfied with the experience. They are:
- ad-free
- lightweight
- offline-first
- focused on simple tasks
- no forced logins or password saving
Just clean tools that do exactly what they’re meant to do. 🤷
Real-World Iteration Matters
This approach also affects how I handle more complex systems.
For example, I had started working on HMI templates, but I stepped back from pushing "Gnoke-OBD2" further because I didn’t yet have a reliable way to thoroughly test the system in real conditions.
Instead of forcing it out, I paused it until the validation environment is solid enough.
That’s part of the same principle — build fast, but only ship what you can properly verify. 🚴
Final Thought
I don’t see AI as replacing understanding. I see it as replacing typing.
If I can describe a system clearly, and AI can translate it into working software that I can verify in real use, then the value is not in writing code.
The value is in building something that works.
Wishing you a productive working week. ✌️
Top comments (0)