Learning Vibe Coding Before the Bot

First question: what is vibe coding?

The conversation started with a very short question: what is vibe coding? At the time, the term described a new way of building software. Instead of writing every line by hand, you explain what you want in normal language and let an AI model generate code.

That idea mattered because traditional programming was not the starting skill. Excel, formulas and some VBA created with help from AI were familiar. Building a full program in Python was not.

Two minutes later: can you teach me?

The next question was even simpler: can you teach me? Gemini answered with a practical path. Learn enough basic programming to understand what is happening, but use AI as the main assistant for creating, testing and correcting code.

Python appeared as the natural language to start with. Not because it was magical, but because it was readable, widely used and surrounded by libraries for data, automation and later market analysis.

The important lesson was not code. It was instructions.

At 19:48 the conversation moved to the part that would shape the next months: prompting. The advice was straightforward. Describe the task clearly. Name the language and environment. Break a big problem into smaller pieces. Give examples. Paste the existing code when asking for a change. When something fails, paste the error and ask what needs to be fixed.

In practice, this became a loop:

Describe what you want. Let AI generate it. Run it. Show the error. Fix it. Repeat.

That loop later became visible in hundreds of project messages. Commands were copied to a server, code was run, errors came back, and AI was asked for a corrected version. It was fast, sometimes surprisingly effective, and sometimes painfully unreliable.

There was a hidden weakness in the idea

Vibe coding made software feel accessible. It also created a dangerous temptation: if AI can write the code, maybe deep technical understanding is unnecessary.

The later history of the project would challenge that assumption again and again. Wrong libraries, broken environments, syntax errors, API problems and code that looked convincing but did not actually do what was expected became part of the learning process.

That does not make the original idea useless. It makes the lesson better. AI can dramatically lower the barrier to building software, but someone still has to test reality.

Why this belongs in the history of AUR

Five days later the idea of a self-learning crypto trading bot would become explicit. Without this earlier experiment in AI coding, that jump would have been much harder. The project did not begin with a team of developers. It began with a person learning how to turn plain-language instructions into working software, one small step at a time.

That basic pattern survives in AUR today, but with a much stricter rule: AI can propose, build and analyse, but evidence has to decide what is true.