Vibe coding isn’t about replacing engineering judgment — it’s about compressing the gap between idea and working software. Over the past year I’ve shipped several side projects using AI-assisted development as my primary workflow. Here’s what I’ve learned.
The term is a bit of a meme, but the practice is useful. Vibe coding means staying in a high-level creative flow — describing what you want in natural language, iterating fast, and deferring the tedious scaffolding to an AI assistant.
The key distinction: you’re still the architect. You make the calls on structure, trade-offs, and quality. The AI handles the implementation details that would otherwise break your flow.
I’ve converged on a tight toolkit:
Before writing a single line of code, I spend 10 minutes writing a plain-English description of what I’m building and why it should feel a certain way. I include the aesthetic direction (quiet luxury, brutalist, playful), the key interactions, and who the audience is.
This brief goes into CLAUDE.md or similar context files that live in the repo. Every AI conversation gets this context automatically, which means I spend less time re-explaining the vision.
For a new feature I write a detailed prompt — sometimes 200–400 words — describing the full shape of what I want. Component structure, data flow, edge cases, styling constraints. The AI generates a rough scaffold. It won’t be perfect, but it gets me 60–70% there in seconds.
Resist the temptation to iterate on bad scaffolding. If the first output is structurally wrong, start over with a better prompt.
Once the scaffold is right, I switch to tight feedback loops:
The mistake I made early was asking for too many changes at once. Small, focused requests get much better results. One visual bug at a time. One API behavior at a time.
The AI will sometimes introduce subtle bugs — unused imports that cause TypeScript errors, or logic that works in the happy path but breaks on edge cases. I protect against this with a simple pre-commit checklist:
# Before every commit:
npm run build # catches TypeScript errors
npx astro check # Astro-specific type checkingMake this a habit. The 30 seconds it takes has saved me hours of debugging deployed errors.
Long context is genuinely powerful. When debugging a hard issue I paste in the full component, the types it depends on, the error message, and the relevant API response shape. The AI can reason across all of this simultaneously in a way that’s hard to replicate by asking narrow questions.
Hallucinated APIs. The AI will sometimes reference methods or props that don’t exist. Always check against the actual docs for libraries you’re less familiar with.
Dependency drift. AI-assisted code can introduce libraries you didn’t ask for, or use older API patterns from libraries you’re already using. A quick npm ls after a large generation is worth doing.
Losing the architecture. When moving fast it’s easy to let the component structure drift into something messy. Every few sessions, step back and ask whether the file structure still makes sense. Refactoring is cheap; shipping a mess is not.
Security blind spots. AI assistants generally write safe code, but they can miss subtle issues around input validation, rate limiting, or auth token handling. Any API endpoint touching user data gets a manual review pass.
The biggest change is treating iteration speed as a first-class metric. With a good vibe coding setup, the cost of trying something is very low. So I try things I’d normally sketch on paper first. Some fail immediately; that’s fine. The ones that work get refined. The result is a much tighter feedback loop between idea and outcome.
You’re not writing less carefully. You’re writing faster, which means you can afford to be more experimental and then converge quickly on what works.
The tools matter, but the workflow matters more. Once you’ve developed a feel for writing effective prompts and maintaining good project context, the specific tools become interchangeable.
Picking a stack is one of the first decisions on a project and one of the hardest to undo. What I look for: the team already knows it, it performs well enough, and it will still be maintained in a few years.
Here is what I would have picked in mid-2025 for a few common kinds of app, plus some design-system choices.
Technology Stack
Key Benefits
// Example: API route with Next.js 14
// app/api/users/route.ts
import { NextResponse } from 'next/server'
export async function GET() {
const users = await fetchUsers()
return NextResponse.json({ users })
}Technology Stack
Architecture Considerations
Technology Components
Best Practices
Technology Components
Architecture Patterns
React Native Stack
iOS Development
Android Development
# Recommended package versions
ml_stack = {
'core': {
'python': '3.11+',
'jupyter': 'lab',
'poetry': 'latest' # dependency management
},
'data_processing': {
'pandas': '2.0+',
'polars': 'latest', # faster alternative
'numpy': '1.24+'
},
'machine_learning': {
'scikit-learn': '1.3+',
'pytorch': '2.0+',
'transformers': '4.30+'
},
'visualization': {
'matplotlib': '3.7+',
'seaborn': '0.12+',
'plotly': '5.14+'
},
'deployment': {
'fastapi': 'latest',
'docker': 'required',
'mlflow': 'optional'
}
}NextUI
Park UI
shadcn/ui
Glassmorphism Implementation
.glass-card {
background: rgba(255, 255, 255, 0.1);
backdrop-filter: blur(10px);
-webkit-backdrop-filter: blur(10px);
border: 1px solid rgba(255, 255, 255, 0.2);
border-radius: 16px;
}Aurora Gradients
.aurora-background {
background: linear-gradient(
to bottom right,
rgba(168, 85, 247, 0.4),
rgba(59, 130, 246, 0.4),
rgba(16, 185, 129, 0.4)
);
filter: blur(40px);
}RESTful Principles
GraphQL Considerations
Frontend Performance
Backend Performance
Consider these factors when making technology decisions:
When updating existing stacks:
None of this is a rule. Start here, then check it against what your team knows and what the project needs.