Building Apps with Vibe Coding as a Non-IT Specialist

1. Why this series starts here

Have you ever thought something like this?

• "Everyone says AI can code now, so why do I still feel lost?"
• "I asked ChatGPT for code, copied and pasted things, then gave up after errors kept piling up."
• "People on YouTube build things instantly. Why does it not work like that for me?"

I started in the same place.

About four years ago, when ChatGPT had just appeared, the phrase "vibe coding" did not even exist yet. I still had to memorize Python syntax, search error messages on Google, and translate Stack Overflow answers while trying to complete code.

My routine was copying code into the ChatGPT web page, copying the error back, changing the prompt, and stitching pieces of code together by hand. The AI was much weaker than today's tools. Even for a small function, I often needed dozens of copy-and-paste rounds. Long code frequently lost context, so I had to start over.

Then agent-style development tools such as Cursor made the process much simpler. Now, with a terminal-based AI coding tool, you can say something like "make this program" and the AI can create folders, write files, run code, and revise the result.

But I also ran into many failures.

• When the context became too long, the AI deleted important logic it had written earlier.
• When my prompt was vague, the result went in a completely different direction.
• The worst moment was when an AI said, "I will initialize the database," and actually wiped it.

After enough of those failures, I learned one thing.

Before asking AI to write code, you need rules, a small design, and a safe working structure.

If you skip that step, AI may move in the right direction for a while and then suddenly overwrite earlier work. To prevent that, I started using an agent.md instruction file and collecting design documents inside a docs/ folder.

These days, this kind of work is often described as harness programming: managing the AI's context and giving it a safe harness so it can work without running wild. Tools such as OpenCode, Claude Code, and Hermes-like agent workflows all support this direction in different ways.

As a teacher working with students who want IT-related jobs, I also learned quickly through conversations with students. They asked, "If AI does everything, why does it keep going the wrong way?" I had felt the same frustration myself.

This series is written from that experience.

Even if you do not know coding yet, you can build a small utility or program with AI.
But the first request should not be "write all the code." The first step is to design, give AI rules, and build documents little by little.

2. What this series promises

This is not an advanced course for professional developers. It is a guided process for people who have real problems in their own field and want to make a small app with the help of IT tools.

So this series follows four promises.

• New terms are explained briefly when they first appear.
• Commands and code are explained with where they are used and what happens when you run them.
• Errors are treated as messages from the computer, not as personal failure.
• We start from roles such as input and output before memorizing tool names.

3. New terms in this post

1. App: a program or tool that makes a specific task easier
2. Input: information the user gives to the app
3. Output: the result the app shows after processing
4. Vibe coding: a way of building software by talking with AI and gradually refining structure and results

4. Do not imagine the app too big

In this series, an app does not only mean something installed on a phone. A small program running on your computer, a tool that reduces repeated work, or a screen that organizes data clearly can all be called an app.

When you first design an app, it is better to think about roles before tool names. Most apps can be understood as "input from the user," "processing by the app," and "output shown to the user."

Think of an app as a small office. There is a reception desk where a visitor submits information, a person inside who organizes and decides what to do, and a drawer that stores processed data.

You do not need to understand processing and storage perfectly yet. Processing will appear again in part 4, and actual saving will be handled later in part 6. For now, just remember this flow: input goes in, output comes out.

5. Why make a small app yourself?

Many AI-based apps and services are appearing now: assignment trackers, assessment record tools, parent-message tools, and more. Many of them are subscription services, and sometimes they cost more than the actual feature feels worth.

Those services can be well made. But in a school or office, one thing often becomes clear.

A quick first draft can be more useful than a perfect product.

Imagine tracking assignment submissions for 30 students. Signing up for an external service, fitting your work into its form, changing settings, and exporting a report may take longer than expected. A small program you make yourself can follow your own input style and output format.

In real work, a human review step almost always remains. AI rarely gives a perfect answer, and even when it does, you often need to adjust it to your local situation. So the important points are these.

• Fast draft: AI can create the rough version quickly, so you can focus on checking and using it.
• Custom fit: the input and output can match your actual workflow.
• No ongoing subscription: once you make it, you can keep using it without a monthly fee.

This series is not trying to replace professional services. The goal is to experience "I can make something like this" and to build the ability to adjust AI-made tools for your own work.

For example:

• You are tired of typing the same kind of document every day.
• You want to see several people's submission status at a glance.
• You want to reduce repeated administrative work.

Those problems are often too small to outsource, but too annoying to keep doing manually. If you can make a small app, you gain another option.

More importantly, you learn how to combine prompts and logic to get the result you want. That skill transfers to many other AI tools later.

Today, you do not need to create any files. The goal of part 1 is simply to feel that a small app is possible. The actual project folder will be created in part 3.

6. Does vibe coding mean you do not need to know code?

Not completely.

Vibe coding is not magic where everything finishes automatically without any understanding. AI can write code, but the human still has to decide whether the code is moving in the right direction.

A real work session looks more like this. You type: "I want a program where I can enter student names and submission status, then see submitted and missing students separately." AI suggests code. You run it and say, "Good. But I want missing students to appear in red." You repeat this cycle: request, run, check, revise.

So this series will not hide every development term. But it will not force too many terms into the first post. Here, we only hold the big picture. Tool names will be explained again when we actually use them.

7. Which AI coding tool will we use?

This series uses opencode as the default AI coding tool. opencode runs in the terminal and works from the project folder you create.

Other AI coding tools follow the same broad pattern. The command name and installation method differ, but the basic idea is similar: run the tool inside a project folder, ask in natural language, and check the files it changes.

Tool	How it usually runs
opencode	run opencode in the terminal
Claude Code	run claude in the terminal
Gemini CLI	run gemini in the terminal
Antigravity	open the desktop app
Codex CLI	run codex in the terminal

When this series shows commands or workflows, it uses opencode as the base. If you use another tool, check the comparison box near the end of each post.

8. How this series will proceed

The rough order is this.

1. Create a project folder on your computer.
2. Prepare places for docs/ and agent.md inside that folder.
3. Write the app purpose in docs/01-plan.md.
4. Build a very small CLI version with Python.
5. Turn it into a GUI version with PySide.
6. Add file saving so it feels more like an app.

The goal of the first post is not tool study. It is to understand the overall route for building an app.

9. What we will do next

You are done for today if...

After this post, you do not need to have any code or files. It is enough if you understand the big picture: "I can build a small app, and I should prepare folders and documents before asking for code."

In the next post, we will open the terminal and learn a few basic commands.

• Open the terminal.
• Check the current location, look inside a folder, and create a new folder.
• Try pwd, ls, cd, and mkdir once each.

We still will not write code in the next post. But once the terminal feels less strange, creating the myproject01 folder in the following post will be much easier.

If you can follow this far, app building has already started.