I Didn’t Want AI to Build My App. I Wanted to Learn How to Build It Myself.

An opinion piece on self-learning, the digital divide, journalism, and how artificial intelligence can help people become builders rather than just users of technology.

I was in Class 7 when I first properly touched a computer. My first lesson was simple: how to turn it on and how to turn it off.

After that, the computer was handed over to me.

My friend Tahir Bilal had almost the same experience. We had a teacher, and we still respect that teacher for introducing us to the computer. But what happened afterwards was something neither of us had planned. From the very next day, we started teaching other students what we had learned.

We were not experts. We barely knew the basics. Yet, somehow, we had started teaching ourselves and others without anyone formally teaching us how to learn.

Looking back, I think that was the beginning of something that would take more than a decade to find its direction.

What made us self-learners was not a sophisticated computer laboratory, an expensive course, or access to professional trainers. It was curiosity. We wanted to know what else a computer could do, and every little discovery made us want to explore further.

We waited years for that curiosity to find the right opportunity.

When the ambition was bigger than the resources

By Class 10, I had started imagining that I could write code and build applications of my own. The problem was that there were no accessible coding courses around us, and the Chenab Valley offered very few opportunities for someone with that kind of ambition.

If you lived in a major city, you might have found an institute, a mentor, or someone who could introduce you to programming. For us, the internet was the classroom, and even that classroom was painfully slow.

We were using 2G internet. YouTube was not the learning platform it would later become for millions of people. Finding a useful tutorial, opening a webpage, and understanding a piece of code could take considerable patience.

Around 2009, I began experimenting with websites on Wapka.mobi, a mobile website-building platform that gave beginners like me an opportunity to work with HTML. It allowed me to create websites, experiment with layouts, and gradually understand how the web worked.

I was convinced I was coding.

Then I came across JavaScript tutorials.

Suddenly, what I thought I understood seemed much more complicated. Looking at the code made my head ache. I wondered how anyone could learn to write something that complicated. I had the desire, but I lacked the guidance to cross that gap.

This is an important distinction that people often overlook when discussing talent. A person can have the curiosity and determination to learn something but still struggle because the right resources, explanations, and support are missing.

I did not stop because I had lost interest. I simply did not know how to proceed.

When Wapka eventually shut down its services around 2014–2015, I moved towards Blogger, Google’s blogging platform. By then, journalism and activism had also begun to occupy an important place in my life.

In 2014, while I was in Class 11, I was writing press releases about protests we organised over basic public demands, including roads and school buses. Our concerns were local, but we understood that documenting them and communicating them to the outside world mattered.

My journey into journalism and local activism is discussed in my booklet Power of Local Journalism. But the desire to build things independently never disappeared. I wanted my own website, my own platform, and eventually my own applications.

The illusion of being a developer

For years, I tried different platforms that promised to turn ideas into mobile applications without requiring much programming knowledge.

At one point, I got access to a friend’s Google Play Console account and uploaded an application I had created using AppsGeyser. I thought I had become an app developer.

Within months, the app or its publishing arrangement was blocked. I never established whether the problem was related to the platform, my application, or something else. What I learned was that creating an application through a website and understanding how an application is built are two different things.

I also tried Android Studio. Repeatedly.

Each attempt ended in frustration. I could not understand the code well enough to make meaningful progress. I would start learning, get stuck, and eventually move on to something else. GitHub confused me, too. I could see that developers were using it, but I could not understand what purpose it served or how it fitted into the process of building software.

I asked friends to develop applications for me. Some agreed, but their commitments and professional lives meant they could not always find the time. That was understandable. They had their own responsibilities, and I could not expect them to put their lives on hold for my ideas.

Hiring a professional developer was not a realistic option either. I did not have the budget.

Meanwhile, the ideas kept accumulating.

I had learned enough about the internet to imagine what I wanted to build, but not enough to build it independently. For years, that gap between imagination and execution remained one of my biggest frustrations.

The turning point came when I stopped waiting

In 2025, some friends introduced me to PowerShell, VS Code, and GitHub and demonstrated a few basic operations. I began experimenting with these tools myself. I used them to draft Right to Information (RTI) applications—something not typically expected of a GitHub user, but then, I am a Journoist—and for other practical work before gradually moving towards software development.

One decision proved particularly important: I asked a friend who had begun working on an application for The Chenab Times to send me the project files so I could continue the work myself.

My friend Farhat Usman, who is exceptionally capable with technology, had also faced resource constraints. He did not have consistent access to a stable laptop or PC. That made it difficult for him to work continuously on the project.

Another friend, Mohsin Hassan, who is currently at Jammu University, discussed various tools and possibilities with me.

Eventually, I reached a point where I had to make a choice. I could keep waiting for someone to build my ideas, or I could take responsibility for learning how to build them.

There is a saying in our local language that captures this perfectly:

Yo’tam Na Paan Ka’rekh, To’tam Bani Na Ke’in.

In Hindi, the meaning is straightforward: Jab tak khud nahi karoge, tab tak kuch nahi banne wala.

Until you try to do it yourself, nothing is going to happen.

I began coding through PowerShell, working with the project files, and using ChatGPT as a guide. The experience was far from smooth. Early AI-generated code often contained errors, and I did not always know how to identify or correct them.

There were times when a suggested solution introduced another problem. A feature that seemed simple in conversation could become complicated when I tried to implement it in an actual project.

But this time, I had something I had not possessed during my earlier attempts: a way to ask questions continuously, examine alternatives, and work through problems one at a time.

I also had years of experience with website development, prompting, and experimenting with digital tools. Some programming concepts were not entirely unfamiliar to me. I had encountered C++ basics, and Dart and Flutter gradually became more understandable as I worked with them.

I was no longer trying to learn everything before building anything. I was learning by building, and the project itself was becoming my classroom.

AI did not replace my learning. It made learning possible.

I use ChatGPT, Claude, Codex, Replit, and other AI-powered tools. But there is a significant difference between how I approached them and how people sometimes assume AI-assisted development works.

I did not simply ask an AI to build my application and accept whatever it produced.

I wanted to understand how to do things myself.

I would ask how a particular feature worked, where a change needed to be made, why an error was appearing, or how one part of the application communicated with another. For a single feature in The Chenab Times application, discussions could continue for hours.

Sometimes the AI’s explanation was wrong. Sometimes its proposed code did not fit the existing project. Sometimes a fix worked in one place but broke something elsewhere. I had to learn to question the answers rather than treat them as instructions that could never fail.

That is one of the most important lessons I have learned from AI-assisted development: the ability to generate code is not the same as the ability to build reliable software.

An application is not just a collection of screens. Its components must work together. Authentication must be handled correctly. Data must be stored and retrieved reliably. Errors must be investigated. Existing features must continue to work after new ones are introduced.

As my projects grew, I realised that I needed to understand not only how to write or modify code but also how to test applications, inspect project structures, work with databases, use version control, review changes, and investigate failures.

GitHub, which once seemed incomprehensible, gradually became a practical part of my workflow. Branches, commits, migrations, testing, and reviewing changes became things I could discuss and work with rather than mysterious terminology.

I also learned that AI tools can confidently suggest the wrong solution. A developer who blindly copies their output is vulnerable to mistakes. A learner who asks why the solution should work, tests it, and investigates when it fails has an opportunity to develop genuine technical judgment.

AI did not remove the need to learn. It gave me a way to keep learning when a human teacher was not available.

Two months, one application, and years of preparation

My determination was particularly evident when I developed ScanPatra V1 in approximately two months.

ScanPatra is a document productivity application built with Flutter. It brings document scanning, OCR, PDF creation, and related utilities into a single workflow, with an emphasis on offline use and local document handling.

Developing it was not simply a matter of generating a few screens. It involved bringing multiple features together, testing how they behaved, identifying problems, and working through technical limitations.

There were difficult moments, but the experience changed how I viewed my own capabilities. Something I had imagined for years was finally becoming a real product that other people could install and use.

ScanPatra eventually reached the Google Play Store. Another application also made it to the store, while Journoist remains under development as I continue building and refining its features.

These are not just three separate projects. They represent different stages of the same journey: from experimenting with simple websites, to struggling with Android Studio, to taking responsibility for real applications.

My work can also be explored through my personal website, AnzerAyoob.com.

The most important change was not that I suddenly became capable of writing perfect code. I did not. It was that I stopped treating my lack of formal training as a permanent barrier.

Journoist: building for a purpose

Journoist is particularly important to me because it brings my experience in journalism and activism into software development.

The application is intended to provide tools for journalists and activists, including verification and research features and a civic campaign system. Its planned features include campaigns, petitions, and a social publishing format called Drops.

Building such a platform presents challenges that go beyond the visible interface. A campaign system needs appropriate data structures, moderation workflows, and reliable handling of signatures. A social publishing feature needs its own rules for visibility, links, interactions, and moderation. Accounts, permissions, and user roles must behave consistently.

These are the kinds of problems that force a learner to go beyond superficial coding.

I have had to work with Flutter and Dart on the application side, PHP and MariaDB on the backend, Firebase authentication, database migrations, and GitHub-based development workflows. I have also learned the importance of protecting existing functionality while introducing new features.

Journoist is still a work in progress, and I do not consider it finished simply because parts of it run on a phone. A functioning prototype and a dependable public application are not the same thing. It still needs careful testing, security reviews, and continued refinement.

That distinction matters. AI can accelerate development, but it cannot make the responsibility for a product disappear. If people depend on an application, its creator must take its reliability, privacy, and security seriously.

The digital divide is also a learning divide

My experience has made me question the way we discuss technological opportunity in places such as the Chenab Valley.

We often speak about the digital divide as a problem of internet connectivity. Connectivity matters, but the divide goes deeper.

It includes the absence of mentors, affordable training, reliable devices, practical learning environments, and opportunities to experiment without fear of failure. It also includes the difficulty of finding someone who can explain a technical concept in a way a beginner can understand.

For years, I had internet access of a kind, but that did not mean I had meaningful access to programming education.

Artificial intelligence can help reduce some of these barriers. Someone who cannot afford a private coding tutor can now ask questions, request explanations, compare approaches, and receive guidance while working on a real project.

But we should not exaggerate what this means. AI does not provide everyone with a computer, reliable electricity, affordable internet, or the time to learn. Nor does it guarantee that the answers are correct. People still need foundational knowledge, critical thinking, patience, and opportunities to practise.

The promise lies in making technical guidance more accessible, not in pretending that every barrier has disappeared.

Our educational institutions should take this opportunity seriously. Students should not be taught merely to use AI to complete assignments. They should learn to use it to understand difficult concepts, build projects, question answers, test hypotheses, and solve real problems.

A student in a remote village should have a genuine opportunity to learn software development even if there is no coding institute nearby.

That should not be an extraordinary privilege.

The real question is what we do with the tools

There is a growing argument that AI will make programming knowledge unnecessary because anyone can describe an idea and obtain an application.

I disagree with that conclusion.

AI may make some aspects of development easier, but building a useful, secure, maintainable application requires much more than describing an idea. Someone must understand the problem, make architectural decisions, assess the generated code, test the result, and take responsibility when something fails.

At the same time, I reject the opposite argument that AI-assisted development is not real development.

If someone uses AI to learn a programming language, understand an unfamiliar codebase, implement features, debug errors, test changes, and gradually become more capable, dismissing that work merely because AI was involved makes little sense.

The relevant question is not whether every line was typed without assistance. It is whether the person understands the system well enough to make informed decisions and is willing to take responsibility for the outcome.

My own experience is proof that the process can be imperfect and still productive. I began with HTML, struggled with JavaScript, failed to understand Android Studio, became confused by GitHub, and spent years waiting for the right circumstances. Eventually, I found tools that allowed me to continue learning through practical work.

I am still learning. I expect to make mistakes, encounter problems I cannot immediately solve, and discover gaps in my knowledge. That is part of software development, not evidence that the journey has failed.

From a computer in Class 7 to building my own applications

When I think about that first computer in Class 7, I remember how little I knew. I could turn it on and off. Yet that small introduction opened a door that I kept trying to walk through for years.

Tahir Bilal and I began teaching other students the very next day. We did not know where that spirit would lead us. We had no elaborate plan, no roadmap, and no idea how much the technology around us would change.

In the years that followed, I moved between websites, journalism, activism, failed attempts at app development, and long periods of frustration. I did not follow a conventional route into software engineering. I had no formal coding education that could take me from beginner to professional developer in a structured sequence.

What I had was a persistent desire to build something of my own.

Today, AI tools have become guides in a journey that began long before they existed. They have helped me turn curiosity into practical skills and ideas into working applications. But they did not create the curiosity, and they cannot replace the judgment I must continue to develop.

My journey also carries a lesson for anyone who believes that a lack of formal opportunities automatically disqualifies them from learning something difficult. The barriers are real, and determination alone does not solve every problem. Yet the absence of a perfect environment does not mean there is nothing you can do.

Start with what is available. Build something small. Ask questions. Read the code. Test it. Break things. Fix them. Learn enough to recognise when a tool is giving you a bad answer. Then move on to something more ambitious.

Do not spend your entire life waiting for somebody else to build what you have imagined.

I once thought that coding was beyond my reach because I could not understand JavaScript tutorials. Years later, I was working on applications involving mobile interfaces, databases, authentication, and backend systems. The distance between those two points was covered by years of curiosity, repeated failures, self-learning, and eventually the assistance of AI.

I did not need AI to give me a dream. I already had one.

I needed the opportunity to learn how to pursue it.

And that, perhaps, is the greatest promise of these tools: not that they will build everything for us, but that they may help more of us learn to build things for ourselves.

About The Author