As LLMs have grown more mature, I've basically been using a "vibe coding" workflow for most business logic at work over the past six months, giving instructions for the AI to write the code, while I mainly focus on review and small adjustments.
Vibe coding is genuinely fast and incredibly practical. Features that used to take three to five days can now be built within half a day with AI's help, followed by another half-day of reviewing, refining, and testing to ensure all the details are correct. By then, the feature is already at a production-ready level. The rise of AI is truly a blessing for software engineers.
In this post, I'd like to share some prompting techniques I've used over the past six months of vibe coding, along with tips that help the AI produce code that lands correctly on the first try and avoids inconsistent quality.
- Human Tasks: System Analysis
- Tip 1: Start by Describing the Goal of the Prompt
- Tip 2: Provide Reference Code for the AI to Copy From
- Tip 3: Tell the AI Which Packages or Libraries to Use
- Tip 4: Specify Which Files Should Be Modified
- Tip 5: Ask for an Implementation Plan Before Writing Any Code
- Bonus: Generate Multiple Versions for Me to Choose From
- Summary
Human Tasks: System Analysis
When requirements come in, I still do the initial clarification myself and decide how the code base should be changed. After all, with experience, my understanding of our own code base is far more accurate than an AI crawling the repo from scratch. During discussions with PMs and stakeholders, ideas about feasibility, modules to update, and parts to push back on naturally come to mind. I'll also check existing designs and shared functions so that I can directly hand them to the AI later in the prompt.
I've also tried giving only the requirements to the AI and letting it analyze everything on its own. This works for small, isolated features, but not for changes that span the entire codebase, because it will miss things. Even Sonnet 4.5 sometimes gets lazy, pretends it's "done analyzing," and silently gives up... So as of 2025, AI can still only act as support in this stage. Real judgment and system architecture decisions still need to be led by humans.
Once the scope of changes is clear, that's when vibe coding truly begins, handing the implementation over to the AI.
Tip 1: Start by Describing the Goal of the Prompt
The first sentence is usually a short description of what I want the AI to accomplish and the purpose of this change. This keeps it focused and prevents it from over-editing unrelated areas. Since the final result will become a git commit, each commit should maintain single responsibility so that future reverts or cherry-picks won't conflict.
My prompts usually start like this:
I am developing an IM web app, and I need to implement auto-closing for conversations that become idle on the customer support side.
or:
Now, our current task is to enable drag-and-drop reordering for the quick-reply items.
Just one clear sentence describing the goal of the requirement.
Tip 2: Provide Reference Code for the AI to Copy From
Since company code bases usually follow established patterns, I like to include relevant code references after describing the requirement. This helps the AI match existing conventions and prevents it from generating code that works but doesn't fit the project's style.
Here's an example prompt:
Here are some existing functions for you to reference:
- The backend API for querying the list of open conversations is located here: /XXX/internal/app/cs/handlers/active_tickets_list.go
- The backend API for closing a conversation is here: /XXX/internal/app/cs/handlers/ticket_finish.go
- The close-conversation logic for real users on the frontend is located here: /XXX/src/pages/customer-service/agent/agent-conversation-check.tsx.
- Also, there is similar frontend logic here: /XXX/pkg/req.js
Company code bases grow large over the years. Directly pointing the AI to a specific place saves tokens and time since it doesn't need to wander around the repo. If there are shared functions the AI should use, include them too. This prevents the AI from reinventing identical logic unnecessarily.
Tip 3: Tell the AI Which Packages or Libraries to Use
There are usually many ways to achieve the same result. For example, backend code may query the DB using raw SQL or ORM. Frontend styling can be done with plain CSS, TailwindCSS, or a component library. To prevent the AI from getting too "creative," I usually explicitly tell it the tech stack we use and the patterns it should follow.
For example:
For the backend, use GORM to query the database. Also, don't hard‑code the table name like this: `db.Table("XXX")`. Instead, use `db.Model(&models.ServiceTicket{})`.
or:
For the frontend, use Shadcn components instead of manually coding <div> elements. Use TailwindCSS, and never write inline styles.
Tip 4: Specify Which Files Should Be Modified
After describing the goal, references, and tech stack rules, the next part of the prompt lists the exact files the AI should modify. This prevents it from guessing and placing code in strange locations.
For example:
This is where I want to implement the new function: /XXX/pkg/conversations.js
or:
Put the new API in this package, and follow RESTful principles and snake_case conventions: /XXX/internal/app/cs/handlers/
If multiple similar files require identical changes, list them all so the AI can handle the modifications in one conversation. This saves time and ensures consistency.
Tip 5: Ask for an Implementation Plan Before Writing Any Code
For a personal side project, I could let the AI start coding at this point, and it would likely be fine. But I still prefer running a dry run first to make sure the AI's approach matches my expectations.
My final sentence usually looks like this:
Now analyze the code base and tell me your implementation plan. Don't start coding yet.
At this stage, the prompt is complete. And the AI will analyze the required changes and propose an implementation plan. If everything looks good, I hand it over to the AI to do the real coding. Then I get up, take a bathroom or pantry break, grab a coffee and some snacks, come back, and let the AI do the heavy lifting. I only step in when permission is needed or when everything is done and it's time for a full code review. That's basically the new work style in the vibe coding era LOL.
Bonus: Generate Multiple Versions for Me to Choose From
The prompt above works when requirements are clear. But when requirements or UI layouts are still fuzzy, I first have the AI generate several versions of the layout using mock data. It then commits each version to a separate branch so I can choose the most suitable one. After selecting, I remove the mock data and hook it up to the real backend.
For example, this is how I've prompted it before:
Create 5 different UI layouts and commit each to a separate branch so I can choose the most suitable one. For now, just use mock data in the `queryFn` within `useQuery`. Let's finish the frontend UI first before moving on to the backend API.
Summary
Vibe coding allows engineers to stop spending all their time writing CRUD and boilerplate. With this workflow, you can deliver in half a day what used to take three to five days. After another half-day of review and refinement, the result is production‑ready. As senior engineers, we can spend more time working closely with stakeholders and PMs to clarify requirements and think through system architecture design.