Vibe Coding & AI

I've been building things differently lately. Less planning upfront, more feeling my way through problems. Not reckless—just trusting that the shape of the solution will reveal itself as I work. I call it vibe coding, though that probably sounds less serious than it is.

The idea is simple: start with a clear aesthetic or functional intuition about what you want, then iterate rapidly until the implementation matches that vision. You're not working from detailed specs or architectural diagrams. You're working from taste.

This isn't new. Designers have always worked this way—sketching, refining, letting the process guide the outcome. What's changed is that AI makes this approach viable for building software, not just designing interfaces.

AI as Amplifier

The main shift is speed. With AI-assisted coding, the distance between "I want this to feel like X" and "here's a working prototype" collapses. You can try five different approaches in the time it used to take to carefully plan one.

This changes how you think. Instead of optimizing for correctness on the first pass, you optimize for iteration. Generate something quickly, see if it feels right, adjust. The bottleneck isn't implementation—it's judgment.

AI is good at patterns. If you can describe what you want with enough clarity—either through examples, constraints, or analogies—it can often produce something close. Not perfect, but close enough to react to. And that reaction (this feels too heavy, this flow is awkward, this interaction is wrong) becomes the next input.

The aesthetic sense matters more now. You need to know what good looks like, even if you can't always articulate why. AI can generate endless variations; you have to be the filter.

Where It Breaks

The failure modes are predictable. Brittle logic that works in the happy path but crumbles under edge cases. Missing constraints that weren't specified because they seemed obvious. Over-reliance on patterns that don't quite fit the problem.

I've shipped things that looked right but had subtle bugs lurking beneath. The surface was polished, but the foundation wasn't sound. That's the trade-off: speed and aesthetic coherence at the cost of rigor.

The other issue is context. AI doesn't know what you know. It can't see the larger system, the design decisions made three months ago, the constraints you're working within. Every prompt is a fresh start. If you don't provide that context explicitly, you get solutions that technically work but don't fit.

This makes vibe coding better for greenfield projects or isolated features than for complex refactors or deeply integrated changes. The less context required, the more freedom you have to iterate purely on feel.

Rules I'm Adopting

I'm developing constraints to keep this grounded:

1. Test your assumptions early. If the vibe says "this should work," write a quick test or prototype the edge case. Don't trust the feeling alone.

2. Separate surface from structure. Aesthetics guide the interface, but the underlying logic still needs to be sound. Iterate quickly on what users see; move slower on what the system depends on.

3. Use AI for scaffolding, not decisions. Let it generate the boilerplate, the repetitive patterns, the first-pass implementation. Keep the architectural choices, the tradeoffs, the context in your hands.

4. Maintain a record of intent. When you make a decision based on intuition, document why. Future you (or future AI) will need that context when the code needs to change.

5. Know when to stop iterating. The vibe can trap you in endless refinement. Ship when it's good enough, not when it's perfect.

What Changes Next

I think this style of building will become more common, especially for solo builders and small teams. The ability to move from idea to prototype to shipped product without layers of planning is powerful. It lowers the activation energy for experimentation.

But it also raises the bar for taste. If anyone can generate a functional product quickly, the differentiator becomes judgment—what to build, how it should feel, what tradeoffs to accept. The craft shifts from execution to curation.

I'm curious what happens when this becomes the default. Do we end up with more interesting, opinionated software because builders can follow their instincts without fighting tooling? Or do we get a flood of technically competent but soulless products because the aesthetic part is harder to automate?

Probably both.

For now, I'm using this approach on side projects and new features—places where the cost of failure is low and the value of speed is high. I'm learning what my intuition is good at and where it needs support. The goal isn't to replace structured thinking, but to expand the toolkit.

Some problems need planning. Others need taste. Knowing which is which might be the skill that matters most.