Vibe Coding 101 for Software Engineers
Vibe coding, or rapidly building software by issuing commands to AI coding agents and accepting all changes, presents an new interaction mode between human and computers. Used well, it eliminates toil and accelerates development iteration speed. Used blindly, it can leaves users confused, frustrated, or worse, a piece of software full with unmaintainable spaghetti, hidden security holes, and runaway LLM bills.
This post blends multiple perspectives on vibe coding into a single, practical guide:
- The background on ai assisted coding and vibe coding
- Getting started with vibe coding
- Best practices with AI assisted codings with software engineering fundamentals
Follow the principles below and you’ll keep the “vibes” while safeguarding your sanity.
Background on AI Assisted Coding and Vibe Coding
AI assisted coding started in 2021, with the release of started with OpenAI Codex which enabled Github Copilot. It enabled very advanced code completion and fill-in-the-middle. Prior to this, most of the assisted coding tools are doing tab completions and inserting template codes such as docstrings.
The release of Claude 3.5 Sonnet in June 20th, 2024 opened up the potential of agentic coding. Here’s the tweet from Andrej Karpathy that coined the term vibe coding
.
There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper…
— Andrej Karpathy (@karpathy) February 2, 2025
Karpathy’s tweet sounds reckless; voice to text input to coding agents, accept every AI diff, paste error messages back, and hope the bug disappears. Carpe diem. Momento mori. YOLO.
This makes perfect sense for a quick prototype, personal application, hackathon, or anything low stakes with low blast radius. If a bug could cost real dollars or embarrass users, we gotta leave the vibe coding zone and need proper engineering discipline.
✅ Common Use‑Cases | ❌ Dangerous Use‑Cases |
---|---|
Throwaway weekend hacks and demos | Software that handles money, personal data, or production traffic |
Exploring new UI/UX ideas at high speed | Apps that must scale reliably or pass a security audit |
Learning to code by “seeing what happens” | Long‑lived products with multiple contributors |
However, coding agents are way more capable than just for Common Use-Cases. We will introduce a more principled approach in doing AI Assisted coding, or “using Coding Agents responsibly to accelerate development.” We will introduce methods to make coding agents work for the Dangerous Use-Cases.
Setting up Coding Agents
Coding Agent Host Selection
There are now many ‘mainstream’ ai assisted coding tools available on the market now, and we will focus on CLIs and IDEs that is applicable to all variations of software engineering. Hence, we will ignore no-code fronteend focused vibe coding tools such as Lovable and v0 and the web-based IDE vibe coding tools like Bolt.new and Repl.it. Yes, I expect none of the above to be used for backend, data science and analytics, devops, infrastructure, machine learning, or platform engineering work.
Let’s treat this as finding a host for our Coding Agent to operate. In addition, let’s treat our Coding Agent as our intern software engineer. This means we need to provide tools to them. The way we can provide tools to coding agents is via using something called Model Context Protocol servers. For all intent and purposes, they work exactly the same as plugins to the current code editors such as VSCode.
The following is a list of popular hosts for our Coding Agents
Editor | Type | MCP Support | Built In Tools |
---|---|---|---|
avante.nvim | IDE | ✅ | |
Cursor | IDE | ✅ | |
VSCode | IDE | ✅ | Web Search, File System, Git, Image |
Windsurf | IDE | ✅ | |
Augment | IDE Plugin | ✅ | |
Cline | IDE Plugin | ✅ | |
Roo | IDE Plugin | ✅ | |
aider | CLI | ✅ | |
Claude Code | CLI | ✅ | File System, Terminal, To-do List |
Codex | CLI | ✅ |
For the rest of the discussion, we will be use Cline and Claude Code as our hosts of choice. Cline works in VSCode as a plugin with wide model supports and MCP supports, while Claude Code works from command line. Everything else works very similarly.
Tools for Coding Agents
As previously mentioned, we need to equip our Coding Agent with tools. While our coding agent can really write code, it needs certain tools to operate well.
Think in terms of the day to day of a software engineer, outside of the meetings, what tools do we have access to in our development process? These include things like web sesarch, git, Github, Jira, terminal, documentations, file systems. For variants of software engineering, JavaScript developers use Chrome DevTools, data science and analystics use Jupyter Notebooks, infrastructure engineers use Kubernetes, game developers uses Unity or Unreal Engines, etc.
In our experience, here are the following must have MCP tools for our Coding Agent.
MCP Tool | Type | Credential Needed | Notes |
---|---|---|---|
claude-task-master | Non-official | ||
Sequential Thinking | Official | ||
Bing Search | Non-official | Yes | |
Filesystem | Official | ||
Gthub | Official | Yes | |
Git | Official | ||
Jira | Non-official | Yes |
Note: Some of MCP servers listed require API keys such as Bing Search or Github. Ask your favorite coding agent to figure out how to get them.
Note: Some of Coding Agent hosts have built in tools, e.g., VSCode Copilot has built in web search, Claude Code now has built in to-do list.
Coding Agents Model Selection
There’s only three viable models for vibe coding. Use other models for suboptimal results. Ask your favorite chatbot on how to obtain credentials.
LLM | Notes |
---|---|
Claude 3.5 Sonnet | Solid choice. |
Claude 3.7 Sonnet | Smart, but sometimes verbose, tend to over code ignoring directions. From time to time cheats by displaying thins are done |
Gemini 2.5 Pro | Solid choice. Frequent rate limiting, and serious API billingn issues |
Coding Agents Rules Files
Software engineers typically go through some onboarding process when joining a project. In the case of open source projects, very typically we would go through README.md
, CONTRIBUTING.md
, CONVENTIONS.md
, CODE_OF_CONDUCT.md
, etc. These files oftentimes provide crucial information on how to setup the projects for development, how to use the projects for their intended uses, and how to make contributions to the project from onboarding issues to coding styles.
Coding agents are no different. They need to understand the context and background knowledge. These are called rules files. Rules files are the README.md
and CONTRIBUTING.md
for coding agents. These files are typically appended to the system prompt to provide project-specific instructions and contexts. the background context. This is different from custom instructions, where the custom instruction are global for user, rules files are local andn project specific.
Rules file for Cline is named .clinerules
. for Claude Code, it is named CLAUDE.md
. For Github Copilot, its .github/copilot-instructions.md
and .github/prompts/*.prompt.md
. They are kept at project root, which sometimes differs from repository root, e.g., monorepos. These files are committed with the code into the code repositories so everyone working on the project can share the same rules files, similar to README.md
, .pre-commit-config.yaml
, or other configuration files.
Vibing with Coding Agents
Aight, now we get everything ‘setup’, we can start vibing with our coding agents. We should treat our AI coding agents as our coding partner in order to ship fast and stay sane. In other words, pair programming.
In Kent Beck’s Extreme Programming Explained, pair programming is a software development technique where two programmers work togther at a single PC. Within the pair, work is split into two roles - ‘driver’ and ‘navigator’. The ‘driver’ is the person at the keyboard responsible for the actual typing of the code being generated. The ‘navigator’ is an active observer and monitor of the code being written. The driver and navigator collaborate on all aspects of the software
development: design, coding, debugging, etc. They are in constant communication, asking and answering questions of each other.
In the case of working with coding agents, the coding agent, given its capabilities in generatig code, will assume the role of the ‘driver’. We, the human developers, will assume the role of ‘navigator’. We should be an active observer and monitor of the code being written. We are only deligating code generation to the ‘driver’, not abdicating our responsibilities as the ‘navigator’.
Coding Agent for Coding
Now we understand the working with coding agents is the same as pair programing, here’s the rhythm we’ve found after many of successful tickets and frustrating nights.
1. Warm-Up: Planning and Workspace
We start where every engineering task begins - Jira. We ask the coding agent to read the ticket (thanks JIRA MCP
!). With these context, we ask the agent to produce a to-do list and save it to /tasks/
folder as in Markdown format. Remember to ask it to generate a checkbox for every single task so we can better keep track (thanks, claude-task-master MCP
!!). To make the agent more deliberate, we can use words in our instructions like think
or ultrathink
.
Now, we can ask the coding agent to create a branch for the Jira ticket (thanks, Git MCP
!~). This will act as a checkpoint that we can load and revert back if the process does not work out as well as expected. And from time to time, it will NOT work well.
NOTE: As the navigator in the pair coding paradigm, the human programmer NEEDs to have the experience and expertise of problem decomposition. This is a non-trivial skill and is the hard ceiling of what the driver can accomplish.
“The most fundamental problem in computer science is problem decomposition: how to take a complex problem and divide it up into pieces that can be solved independently.” – John Ousterhout
For some of the security best practices, we might consider to run our code in a sandbox dev container, e.g., Claude Code, though this is not yet a common developer tooling infrastructure widely available to everyone.
2. Execute: Yolo Vibe
With our tasks plan on hand and git branched, time to yolo. Ask the agent to start working on the tasks plan, remember to generate the test code first, especially when working on backend or library codes. This is the coding agent equivalent of test-driven-development or ping-pong pair programming. For every task completed, ask the agent to checkoff the box on the to-do list.
Automatically accept all changes. Always. Resist the urge to micromanage. The core benefit of working with coding agent is to shorten the OODA loop. Reviewing every single step of the way is a waste of time. Do NOT be that human in the loop. Stay out of the loop.
Future be like tab tab tab
— Andrej Karpathy (@karpathy) August 26, 2024
3. Trust and Verify
Now, at some point, hopefully sooner than later, all of the boxes on the task list is checked. We can then run the full test suite or click through the UI for front-end work. If everything passes locally, we can then open a PR as normal to trigger the full continous integration (CI) suite. The tasks in the to-do list will provide the perfect context for filling out Github pull_request_template.md.
. As a best practice, always have two reviewers or have another code owner to review.
If tests fail, it’s debugging time. We spin up a fresh chat thread containing the expected behaviour, the actual error, and full logs. Do a Git checkpoint. Clean context helps tremendously to increase the signal-to-noise ratio instead of using the full context. Give it a few tries, and if the coding agent cannot solve this, time to switch roles and take the drivers seat!
Coding Agent for Code Understanding
One core tasks we as software engineers commonly need to do is to be quickly onboarded to an code base and make contributions. Coding agents shines here; it can parse through code bases at a very fast pace, understand its structured and explain how it works. As an example, I’ve wrote Poking Around Claude Code despite that TypeScript/JavaScript is not my daily programming language.
In software engineering, we very commonly describe our program in graphical diagrams. The following are common diagrams used to understand how a code base work. These ranges from high level architecture diagrams to state machine diagrams (agents!!). Or, for a specific workflow, e.g., login or checkout, sequence diagrams. Or even, entity relationship diagram to understand the data modeling. We can ask coding agent to generate all of these diagrams for our own information.
NOTE: we can also include these in the rules files to provide coding agents more bounded guidelines on how to contribute to our code bases.
Diagram Type | Primary Purpose | Key Aspects Understood | Common Use Cases / When Most Useful |
---|---|---|---|
Architecture Diagrams | Show high-level system structure, components, and interactions. | Big picture, technology stack, deployment overview, system boundaries, communication paths. | System design, onboarding new team members, technical discussions. |
Sequence Diagrams (UML) | Illustrate object/component interactions over time for a scenario. | Dynamic behavior, message flow between objects/components, collaboration timing. | Analyzing specific workflows (e.g., login), debugging interactions. |
State Machine Diagrams (UML) | Model the lifecycle/behavior of objects with distinct states. | Object states, valid transitions between states, event handling, object lifecycle. | Modeling objects with complex states (e.g., orders, user sessions). |
Flowcharts / Activity Diagrams (UML) | Describe step-by-step logic of a process, algorithm, or workflow. | Detailed procedural logic, decision points, loops, sequential steps, workflow. | Detailing specific algorithms, business process mapping, function logic. |
Class Diagrams (UML) | Show static structure of code (classes, attributes, methods, relationships). | Code building blocks (OOP), data members, operations, inheritance, associations. | Object-Oriented design, understanding codebase structure, refactoring. |
Entity-Relationship Diagrams (ERDs) | Model the structure and relationships within a database. | Data model, database tables/entities, columns/attributes, table relationships. | Database design, understanding data persistence, query planning. |
It take a combination of the above diagrams to fully grasp how a software system works. So be very tactical when generating these diagrams; focus on the context surrounding the incisions only to save time.
Tips and Tricks
Software Stack Selection
Large language models and their varients are, at the end of the day, machine learning models built using deep neural networks. Thus, more frequently appeared data data will tend to have higher quality outputs. For coding agents, this means that their capability will be much stronger in the common programming languages and frameworks.
This means stacks like Python FastAPI, Numpy, and PyTorch, Java Spring Boot, JavaScript Node and React, Unity C#, and Unreal Engine C++ will be much better choice for development choices vs the more recent and esoteric languages or framework choices, e.g., Julia or Mojo.
NOTE: this does mean coding agents will NOT work well with proprietary in-house infrastructures, toolings, and platform ecosystems. They simply do not have enough knowledge of those and injecting enough knowledge in context is simply unrealistic regardless of the context length of the large language models. The models would need to be fine-tuned
Codebase and Documentation Organization
Use monorepo.
A monorepo plays to an AI coding agent’s strengths. Because every service, library, and shared schema lives in one tree, the agent can traverse the entire codebase in a single context window instead of searching, identifying, and stitching together knowledge from scattered repositories. Cross module calls, version constraints, and build rules are all visible at once, so the agent can reason about dependencies and refactor safely without brittle steps. Atomic commits touch multiple layers—data model, API, infra—without the overhead of synchronizing repo histories or coordinating inter-repo pull requests, which keeps the agent’s OODA loop tight. CI pipelines, code-search, and task orchestration are also unified, simplifying prompts and reducing toolchain sprawl.
In short, a monorepo turns the whole system into one coherent “language model playground”, allowing the agent to generate fixes and features faster and with fewer context leaks than a multi-repo setup.
Use monorepo.
Common Pitfalls
Pitfall | Why It Hurts | Antidote |
---|---|---|
Context‑window amnesia | The larger your codebase, the more the LLM forgets previous files and rules, injecting duplicate or broken logic. | Periodically summarise architecture in a fresh prompt; write docs the AI can ingest. |
Invisible security flaws | Leaked secrets, unsanitised inputs, wide open CORS policies, easy for an LLM to slip in. | Scan commits, run dependency checkers, add basic auth & rate limits up front. |
Rules rule
Some might have spotted a major issue with the proliferation of vibe coding tools rules files. There’s NO standards with regards to rules files. Every coding agent has rule files per its own definition and setup. It is becoming an unmanagable mess. The best practice to manage this is to use one of them as the original, and use symbolic links (symlinks) to propagate for other code editors.
To regain sanity, please see this repository for better setup examples with symlinks.
Conclusion
Embrace the vibes and keep your helmets on.
Vibe coding is the fastest bridge between idea and interactive demo the software world has ever seen. Used thoughtfully, it’s a super accelerant for learning and creativity. Ignore its limits, and you’ll crash into the same walls that disciplined engineering has been avoiding for decades.
Move fast with stable infrastructure. Stay curious. Read the diff.
References
- For Writing Software, a Buddy System
- OpenAI Codex
- Github Copilot
- Claude 3.5 Sonnet
- Claude Code: Best practices for agentic coding
- https://twitter.com/karpathy/status/1827921103093932490
- https://x.com/karpathy/status/1886192184808149383
@article{
leehanchung,
author = {Lee, Hanchung},
title = {Vibe Coding 101 for Software Engineers},
year = {2025},
month = {05},
howpublished = {\url{https://leehanchung.github.io}},
url = {https://leehanchung.github.io/blogs/2025/05/04/vibe-coding/}
}