Vibe Coding on KnightLi Blog

easy-vibe: A Learning Map for Vibe Coding Beginners

Sat, 16 May 2026 22:44:43 +0800

easy-vibe is an open source Vibe Coding learning project from Datawhale. It is not aimed at developers who are already fluent with AI coding tools. It is aimed at students, product managers, designers, operators, indie developers, and technical hobbyists who are just starting with Vibe Coding.

The value of this project is not that it lists another batch of AI tools. It turns “how to start building projects with AI” into a learning path that is easier to understand. For many beginners, the hard part is not knowing that Claude Code, Cursor, MCP, or Agents exist. The hard part is knowing what to learn first, how to practice, and when to move into more advanced tools.

Beginners Need a Path Most

Vibe Coding has become popular in recent years, but it is not very friendly to beginners.

On the surface, as long as you can describe a requirement, you can ask AI to write code. In reality, as soon as the task becomes slightly more complex, problems appear: the requirement is unclear, the model edits the wrong file, the project structure is confusing, errors are hard to handle, dependencies fail to install, prompts become messier, and the workflow falls back to “copy code into a chat box”.

So getting started with Vibe Coding cannot only mean learning “how to write prompts”. It needs to solve several things:

How to split an idea into executable tasks;
How to let AI understand a project structure;
How to read code generated by the model;
How to handle errors and iterate;
How to use the terminal and local development environment;
How to move from web chat to real AI coding tools.

This is where easy-vibe matters: it tries to organize these topics into a learning route, instead of leaving beginners lost among tools, tutorials, and terminology.

It Is a Roadmap, Not a Single Tutorial

According to the project description, easy-vibe covers basic tutorials, interactive exercises, visual content, RAG, terminal tools, AI coding tools, and more advanced topics such as Claude Code, MCP, Skills, and Agent Teams.

This structure is suitable for beginners because AI coding is not a single skill. It is a combination of abilities:

Describing requirements;
Splitting tasks;
Reading projects;
Asking the model to edit code;
Running and verifying results;
Iterating based on errors;
Turning repeated workflows into tools or skills.

If you only learn one tool, it is easy to be constrained by that tool’s interface. Switch models, editors, or CLIs, and the workflow becomes unclear again. A roadmap helps build the working method first, then places tools where they belong.

Especially Useful for Non-Programmers

The biggest appeal of Vibe Coding is that it lets non-professional programmers build prototypes.

Product managers can turn product ideas into interactive demos. Designers can validate interaction logic. Operators can write internal tools. Students can quickly build course projects. Founders can validate demand early. These people do not necessarily need to become full-time engineers in the traditional sense, but they do need a method for “letting AI help me turn ideas into working things”.

This is also why easy-vibe fits the Chinese community. Many Chinese users already know AI can write code, but they still lack systematic beginner materials. Development environment, prompts, project structure, debugging methods, and Agent tools are easier to learn when explained clearly in Chinese and paired with exercises.

For these users, the most important thing is not to learn a complex framework immediately. It is to complete a full loop first: propose a requirement, generate a project, run it, find problems, keep modifying, and finally get a usable version.

The Advanced Part Moves Toward Real AI Development Workflows

The Claude Code, MCP, Skills, and Agent Teams mentioned in easy-vibe are no longer just beginner concepts.

Claude Code represents terminal coding Agents: the model can enter a local project, read files, edit code, and run commands. MCP solves tool and data source integration, so the model is not trapped in a chat box. Skills preserve reusable workflows, such as fixed project generation, document organization, test checks, or content production processes. Agent Teams further split tasks across multiple agents.

These topics may feel distant for beginners, but they are worth understanding early. The direction of Vibe Coding is already clear: from “let AI write a piece of code” to “let AI participate in a complete project workflow”.

If a learning route stops at prompts, it will quickly fall behind tool evolution. On the other hand, if every advanced concept is thrown at beginners immediately, they will not know where to start. The useful part of easy-vibe is that it places these topics on a gradual upgrade path.

Two Mistakes to Avoid

The first mistake is thinking that Vibe Coding means you can ignore code entirely.

AI can generate a lot, but the user still needs to judge whether the result is correct. At minimum, you need to understand the project structure, know how to run it, and roughly know where an error is happening. Even if you do not write complex code, you still need basic engineering common sense.

The second mistake is thinking that more advanced tools are always better.

Beginners do not necessarily need Claude Code, MCP, or multiple Agents at the start. A better order is to first build a feedback loop with simple projects, then gradually introduce the terminal, version control, testing, tool calling, and automated workflows. Tools should match task complexity; otherwise they look powerful but have no clear use.

How to Use It

If you are just starting with Vibe Coding, you can use easy-vibe as a learning checklist.

Start with basic concepts and simple exercises. Do not rush to chase every tool. Build a small project, such as a personal homepage, data dashboard, form tool, automation script, or knowledge base demo. During the process, observe where AI helps and where you still need to confirm things yourself.

Once you can complete small projects consistently, move into more complex topics:

Use terminal tools to work with local projects;
Use Git to manage each change;
Use RAG to connect your own materials;
Use MCP to connect external tools;
Use Skills to solidify repeated workflows;
Use Agent Teams to split complex tasks.

Learning Vibe Coding this way is not just learning to ask AI. It is learning to put AI into your own workflow.

Conclusion

easy-vibe is best seen as a Chinese learning map for Vibe Coding. It organizes scattered AI coding concepts, tools, and exercises into a route that helps beginners move from “I heard AI can write code” to “I can build a project with AI”.

The real value of Vibe Coding is not that it lets people skip all learning. It lowers the threshold from idea to prototype. You still need to understand requirements, organize tasks, verify results, and control risks. But many repetitive, tedious, and blocking steps can be handled with AI assistance.

If you want a systematic entry point into AI coding, without getting trapped immediately in tool names and complex engineering setup, easy-vibe is a good place to start.

Do Not Push API Keys to GitHub: A Secret-Leak Prevention Guide for AI Coding

Sat, 16 May 2026 16:26:50 +0800

AI coding lowers the barrier to building software, but it also brings many engineering security problems to beginners and non-engineering users.

One of the most common incidents is pushing API Key, Secret, Token, database connection strings, or .env files to a public repository. Locally, these files may look like ordinary configuration that keeps the app running. Once they enter a public GitHub repository, they become credentials that can be scanned, called, and abused automatically.

Secret leaks are not rare. GitGuardian’s 2026 report says public GitHub commits in 2025 contained about 28.65 million new hardcoded credentials, and AI-service credential leaks grew 81% year over year. The issue is no longer just carelessness. AI coding, rapid prototyping, and public hosting are amplifying the scale.

Why Beginners Leak Keys More Easily

Many AI agents and small tools have two “repositories”: one on the local disk, and one visible to the world on GitHub. The problem is that beginners often do not understand the boundary between the two.

During local development, config.json, .env, and settings.yaml may contain API keys. After git add ., git commit, and git push, those files may be uploaded in full. Once a repository is public, scanning bots do not need to understand your business logic. They only need to match a secret pattern.

AI coding makes this worse:

AI-generated examples may place OPENAI_API_KEY = "sk-..." directly in source code.
Beginners often hardcode secrets in frontend code, scripts, or config files just to get the project running.
Many vibe coding platforms can deploy apps directly without going through GitHub push protection.
Users may not know which files, APIs, or default permissions exist inside an AI-generated project.

In short, AI can help you build something that runs faster. It does not automatically take over the security responsibility.

`.gitignore` Is Not Decoration

Git manages version history, GitHub hosts code, and .gitignore tells Git which files should not enter that history.

A basic AI project should at least ignore these:

.env
.env.*
*.key
*.pem
config.local.*
secrets.*
credentials.*

But .gitignore alone is not enough. It only prevents untracked files from being added later. If a secret file has already been committed, adding it to .gitignore will not remove it from history.

A safer habit is:

Create .gitignore at the beginning of a project.
Store API keys only in environment variables or local config.
Provide .env.example with placeholders, not real secrets.
Run a secret scanner before committing, such as gitleaks, trufflehog, or GitHub Secret Scanning.

Deleting the File Is Not Enough

If a key has already been pushed to a public repository, the first reaction should not be “delete the file and commit again.” Revoke or rotate the key first.

Git records history. Even if the latest commit removes the file, old commits, forks, clones, caches, and scanners may still contain it. GitHub’s documentation also recommends revoking or rotating passwords, tokens, and credentials as the first step.

Recommended order:

Revoke the old key in the provider console and create a new one.
Check billing, usage logs, suspicious IPs, and unusual traffic.
Remove hardcoded secrets and switch to environment variables or a secret manager.
Clean sensitive files from repository history with git filter-repo or BFG.
Enable GitHub Secret Scanning and Push Protection.
Check CI/CD, deployment platforms, cloud functions, and frontend build artifacts for the old key.

For OpenAI, Anthropic, DeepSeek, cloud providers, payment services, email services, and databases, a leaked key can lead to more than unexpected bills. It may expose data, enable abuse, affect the supply chain, or get business accounts banned.

Real Secrets Do Not Belong in Frontend Code

Many beginners put API keys into frontend JavaScript because the page works:

`1`	`const apiKey = "sk-xxxxxxxx";`

This is effectively public. Browser code, network requests, source maps, and build artifacts can all be inspected. Any key that must remain secret should not appear on the client side.

The correct approach is to let the frontend call your own backend, and let the backend read environment variables and call the third-party API:

// frontend
await fetch("/api/chat", {
  method: "POST",
  body: JSON.stringify({ message })
});

Then the server uses the environment variable:

1
2

// server
const apiKey = process.env.OPENAI_API_KEY;

This keeps the secret in the server environment instead of exposing it to every visitor.

Vibe Coding Does Not Remove Security Responsibility

Vibe coding is not only a GitHub leak problem. Many apps are published directly from AI coding platforms to the public internet, bypassing traditional code review, repository scanning, and security testing.

Recent RedAccess research found a large number of publicly accessible assets generated or hosted by AI coding tools, some exposing corporate data, personal information, or internal files. The lesson is simple: when “can deploy” becomes too easy, people often forget to ask “should this be public?”, “should this only be internal?”, and “does it have access control?”

Before publishing an AI-generated app, ask:

Does this app really need public access?
Does it have login, authentication, and permission isolation?
Are database URLs, API keys, tokens, or webhook URLs exposed in frontend code?
Are third-party API quota, domain, permission, and expiry limits configured?
Can keys be disabled and deployments rolled back quickly after an incident?

AI-generated code still needs security review. The less code you personally wrote, the less you should assume it is safe.

Checks to Run Now

Start with your own GitHub account. Search your username together with:

API_KEY
SECRET
TOKEN
OPENAI_API_KEY
ANTHROPIC_API_KEY
DEEPSEEK_API_KEY
.env
config
credentials

If you find a real key, rotate first and clean up later. If it ever entered a public repository, treat it as leaked.

For future AI projects, use a fixed process:

Write .gitignore before writing business code.
Use .env.example to document required variables.
Put all secrets in environment variables, not source code.
Give API keys minimal permissions, quotas, and expiry dates.
Enable GitHub Secret Scanning and Push Protection.
Let AI help with a security review before publishing, but do not trust AI alone.

The danger of AI coding is not simply that it may write bad code. It gives many people the ability to publish unsafe apps to the public internet for the first time. Writing fast is not the problem. Handing out secrets, data, and permissions is.