Vibe Coding Without Losing Your Edge
How do you feel after you use AI to code a new feature or create a document? Does it feel fulfilling? Or a bit empty?
That empty feeling often comes from distance. The code lands, tests pass, but it feels like it happened next to you instead of through you.
We can get that connection back. The aim this week is simple: maintain the "Vibe Coding" speed while staying present in the parts that build pride in your work. You will make key decisions, define boundaries, and deliver code that you can explain and stand behind.
I'll walk through a straightforward way to work with assistants that restores ownership, keeps you learning, and leaves you satisfied with what you shipped.
|
|
Your Next Read
If you want a deeper understanding of AI coding assistants, I'm currently reading "Vibe Coding" by Gene Kim and Steve Yegge.
It's a pragmatic guide to thinking about AI coding and how to keep it in check.
|
Own the Code
If you want AI to speed you up without disconnecting you from the work, start by taking clear ownership. You are the author. The assistant is a fast pair who drafts, searches, and scaffolds. Treat it that way and your confidence goes up, not down.
Here are a few ways you can get back ownership of the code you write:
- Write the contract first. Define the interface, the types, and one or two tests that demonstrate the behavior. Then let the assistant fill in the middle. If "done" currently means "it runs," You need to dig deeper to understand what the goal is.
- Rename and shape. Replace generic names, align terms with your domain, and trim unnecessary cleverness. If you can't hear your voice in the code, keep editing.
- Ask for reasoning. Before accepting a draft, have the assistant explain the tradeoffs and potential failure paths. Keep what fits, rewrite the rest in your style.
- Leave a short decision note. Three to five lines in the PR: why this design, key risks, and what to revisit later. It speeds reviews and helps you understand what was done and why.
Once ownership is back in your hands, the next step is to use the assistant to amplify your intent without setting the direction for you. That is where "augment, don’t replace" comes in.
Augment, Don't Replace
The assistant should help you leverage your strengths more effectively. It should not choose the problem, the pattern, or the boundaries. When you supply the parameters, it fills the gaps. When you let it pick the parameters, you end up editing around someone else's idea, and the work feels borrowed.
Prompt Framing: Intent → Constraints → Pattern
- Intent: one or two sentences on the outcome and who it serves.
- Constraints: inputs, outputs, performance limits, failure rules, and any security or compliance notes.
- Pattern: the design you want. Name it plainly. Example: "Use a thin controller, push logic into a service, and cache reads with a 5-minute TTL."
Hand that frame to the assistant and ask the AI to draft to your spec. You stay in charge because the spec is yours.
Here is what it looks like in practice:
Intent: add a CSV import for partners to bulk-create records.
Constraints: 10k rows, reject on malformed header, partial failures logged, 30s p95.
Pattern: streaming parse into a service, validate per row, batch writes at 500.
What the assistant provides should match the shape you set. If it wanders, you do not regenerate forever. You correct once, restate the spec, and continue.
Two prompts that keep you in the driver's seat
- "Draft to this interface and keep these constraints. Offer two variations and compare them in five lines."
- "List the top five failure modes for this design, map each to code locations, and propose one test per failure."
With direction set by you and drafting handled by the assistant, the next step is to turn each session into a lesson, helping you learn as you build.
|
|
Where can AI save you time?
My friends at Big Creek Growth put together a quick survey to spot the repetitive work you can hand off to automation.
|
|
Don't Stop Learning
If you want the work to feel like yours, make the assistant explain itself. Treat each suggestion as a draft you're reviewing, not a truth you're accepting.
Start with the why. Ask for the design choice it made, the tradeoffs it considered, and when an alternative would win. If the explanation is thin, the code is too. Edit until both are clear.
Map the edges. List likely failure modes, point to where each is handled, and propose one test per risk. You'll spot gaps faster and keep your instincts sharp.
Teach it back. "Explain this to a new hire in five bullets," or "Summarize how this works in one paragraph in plain English." If you can't repeat that explanation in your own words, keep refining.
Two prompts that pull their weight:
- "Compare this approach with two alternatives. Name the tradeoffs and when each would be better."
- "List the top five failure modes for this design, where they occur, and one test for each."
Close the session with a short note to yourself: what changed, why it works, and one thing to revisit. That small habit keeps you learning while you ship, and the work feels connected again.
With ownership restored and learning built into the workflow, the last piece is rhythm.
A Sustainable Loop
You need a rhythm you can repeat as you develop your features. This loop keeps you engaged while still allowing you to maintain speed.
1) Frame the work
Write the contract first. Define the interface, inputs, outputs, and the one or two tests that prove behavior. Say what "good" looks like.
2) Set direction
State your intent, constraints, and the pattern you want. Tell the AI assistant which modules to work on and which to leave untouched.
3) Generate, then choose
Request two or three drafts that adhere to your specifications. Pick one. Keep the parts that fit, and edit the rest into your style.
4) Validate behavior
Run the tests you wrote. Add one failure case. If something feels brittle, simplify the design before proceeding.
5) Leave a short record
Write a brief note in the PR: why this design, key risks, and what to revisit later. Future you should understand it in seconds.
You can run this loop every 10-20 minutes as you develop your feature. It restores ownership, limits wander, and makes the work feel like yours again.
AI can speed up delivery, but it can also push you a step away from your work. Take back authorship by writing the contract and tests, setting the pattern, and using the assistant to draft to your spec while it explains tradeoffs and failure paths.
You end with code you understand and can defend, reviews move faster, and your instincts get sharper. Keep running the loop, and you'll maintain your speed while regaining the connection and pride in your work.