Vibe Codingで身につけたい10の習慣、あなたはいくつできていますか？【前編】This article outlines practical habits developers should adopt when using…

Vibe coding, the practice of building software largely by describing intent in natural language and letting an AI assistant generate the code, has moved from novelty to daily workflow for many developers. As tools such as Cursor, GitHub Copilot, Windsurf and Claude Code lower the barrier to producing working code, the real differentiator is shifting away from raw typing speed toward the habits that keep AI-generated output correct, maintainable and secure. A recent Zenn post frames this shift as a set of ten habits worth cultivating, presented as the first half of a two-part guide aimed at beginners and intermediate developers who want to audit and refine their own workflow.

The term "vibe coding" is generally credited to Andrej Karpathy, who in early 2025 described a loose, conversational style of programming in which the developer leans heavily on the model and accepts much of what it produces. The article's underlying argument is that this convenience cuts both ways. The same speed that lets you ship a prototype in an afternoon can also accumulate hidden defects, brittle structure and code you do not fully understand. The habits it recommends are therefore less about any single tool and more about the discipline that surrounds the tool.

A recurring theme in the first part appears to be the quality of the instructions you give. Vague prompts tend to produce plausible-looking but misaligned code, so the piece encourages developers to be explicit about inputs, outputs, constraints and edge cases rather than expecting the model to infer them. Closely related is the practice of supplying persistent context. In Cursor this often means maintaining project rules, historically configured through a .cursorrules file and now commonly organized as rules in the newer project settings, so that conventions such as language version, folder structure and preferred libraries do not have to be repeated in every request. Providing the assistant with the relevant files or symbols, rather than letting it guess, is presented as a foundational habit.

Another emphasis is working in small, verifiable steps instead of asking the AI to generate an entire feature at once. Smaller increments make it easier to spot where the model went wrong, keep each change reviewable, and reduce the risk of a large, opaque diff that is hard to reason about. This pairs naturally with disciplined version control: committing frequently gives you a safe point to return to when an AI-driven change breaks something, which is especially valuable when an agent edits many files in a single pass. The guidance here mirrors long-standing software engineering advice, but it takes on new weight when a tool can rewrite dozens of lines in seconds.

Perhaps the most important habit the article stresses is reviewing what the AI produces rather than accepting it on trust. Reading generated code, questioning unfamiliar patterns, and confirming that it actually does what was intended are framed as non-negotiable, because the developer remains responsible for the result regardless of who or what wrote it. Automated tests are likely to feature as a complementary safeguard, giving a fast, repeatable way to confirm that AI-assisted changes have not introduced regressions. Together these practices push back against the failure mode where code appears to work but has not been meaningfully verified.

This advice sits within a broader industry moment. Vendors are moving quickly from simple autocomplete toward more autonomous agents that plan and execute multi-step tasks, seen in Cursor's agent mode, GitHub's evolving Copilot features and Anthropic's Claude Code. As that autonomy grows, the surface area for subtle mistakes, security oversights and unwanted dependencies grows with it, which is part of why guides like this one focus on human oversight rather than tooling alone. Concepts worth understanding before adopting these habits include version control basics, testing fundamentals, and how large language models handle limited context windows.

The overall message of the first installment is that vibe coding rewards structure rather than replacing it. Readers are invited to treat the list as a self-check, counting how many habits they already practice and noting where their workflow could tighten. The piece promises a second part to complete the set of ten, and while the specific remaining habits are not detailed here, the framing suggests they will extend the same principles of clarity, verification and accountability into more advanced territory.