To Vibe or Not to Vibe: The Engineer's Hamlet Moment

About this post: This essay began as a structured draft and was developed collaboratively with Claude Code—a fitting example of the vibe engineering it explores.

There’s a moment in Hamlet—the one every high school poster milks—where Shakespeare gives us the existential question: to be or not to be. Hamlet holds the skull, stares into mortality, and considers the weight of the future.

I’ve been thinking about that image recently, but through the lens of software engineering. We have our own version of that skull in hand, and the question has changed:

To vibe code or not to vibe code—that is the question.

Not whether AI will reshape our industry. It already has. The question is whether we choose to meet that progress head-on, resist it, or try to sit safely on the sidelines while the wave moves forward.

Progress Doesn’t Ask for Permission

The pattern is always the same: industrial revolution → mechanical automation → global manufacturing → software → AI.

Every new wave arrives, whether we like it or not. Individually, we don’t control progress. What we do control is our alignment with it.

Do we unionize around the old ways to protect familiarity? Or do we recognize that the next stage of evolution doesn’t wait for buy-in and choose to participate?

This tension is not new. But AI has brought it directly to the engineer’s desk.

When AI Coding Meant Tab-Tab

When GitHub Copilot landed, most engineers understood AI coding through a single primitive: autocomplete with better marketing.

I was there too.

Back in 2021, I built a small text adventure game as a gift—a personal project for a very meaningful moment. I didn’t have a full blueprint; I built it screen by screen, scene by scene, as the story unfolded in my head.

Copilot helped generate the JSON, the scaffolding, the boilerplate. It was useful, but it wasn’t transformative. It was the “tab-tab era”: AI wasn’t a collaborator. It was a convenient typist.

And at the time, that felt fine.

But Vibe Coding Isn’t Autocomplete

The real promise of AI showed up later—with ChatGPT, Claude, and now agentic systems. AI stopped being a predictive keyboard and started becoming:

A research assistant
A planner
A systems thinker
A brainstorming partner
An executor
A reflector that amplifies your understanding

This is the shift from “type a line and let AI finish it” to “present a problem, build context, orchestrate a solution.”

This is vibe coding. Not completing code—but shaping code, systems, and ideas through an iterative partnership.

As I wrote in my recent post on handcrafted software, we’re entering an era where guiding agents through intent matters more than typing every line ourselves. But that guidance requires a different skillset—one many engineers haven’t yet developed.

How Engineers Choose Their Relationship with AI

I’ve noticed that engineers fall into a few familiar patterns.

1. The Resisters

They reject AI because they can’t trust its intermediate output. They expect perfection from step one, when even humans don’t write perfect code in a first pass.

2. The Tab-Tappers

These are the engineers who treat AI like autocomplete. They’re comfortable with the tiny surface area, uncomfortable with letting AI touch anything architectural.

3. The Collaborators

They understand that engineering is inherently imperfect and iterative. They use AI the same way they mentor a junior engineer: with guidance, correction, and patience.

4. The Vibe Engineers

They treat AI as a system to orchestrate. They plan with it, research with it, design with it, scaffold with it, test with it. Not because AI is perfect, but because iteration is a feature, not a bug.

And here’s the interesting part: engineers often think “AI isn’t good enough for me,” but the truth is usually simpler—they haven’t yet invested in understanding how to steer it.

Empathy as an Engineering Skill

It may sound odd, but using AI well requires a form of empathy.

AI doesn’t “understand” your intention. It infers meaning from messy tokens and probabilities. When it fails, it isn’t being stupid—it simply didn’t receive enough clarity, structure, or constraints.

Treating AI with the same empathy we’d give a teammate transforms the dynamic:

Instead of frustration → iteration
Instead of “bad output” → “misaligned prompt”
Instead of one-shot expectations → progressive shaping

Leading AI systems is leadership in miniature. It’s the same muscle.

This connects to something I learned working with mainframes in the Israeli Defense Force back in 2009-2012. Those systems were unforgiving. If your job control language was imprecise, the mainframe wouldn’t guess what you meant—it would fail. But that precision taught me to think clearly about intent, constraints, and communication.

AI is different in many ways, but the fundamental lesson remains: clarity and empathy in how you communicate with systems yields better results.

Why Some Domains Shine and Others Lag

Frontend and presentational layers produce uncanny results with AI today. It’s no coincidence that many successful AI coding products focus on UI building, often bundling their own stable backend layers under the hood.

Backend, infrastructure, distributed systems—these are trickier today. But the trajectory is inevitable.

We’re watching the evolution of no-code builders… except this time, the ceiling is much, much higher.

When I recently revived this blog after years of dormancy, Claude Code helped analyze the broken Gatsby setup, suggest migration paths, and implement fixes across the stack. What would have taken days of manual debugging took hours of collaborative problem-solving.

Should You Invest in Vibe Coding Now?

Some engineers argue: “Why spend time mastering this now? In a few years it will be fully automated anyway.”

But every technological leap follows the same pattern:

Those who invest early gain the mental structures, intuition, and context to participate in—and influence—the revolution.

Those who wait become users, not shapers.

Even if the tools get exponentially better, the engineers who already know how to think with them will always have an advantage.

This is not about job preservation. It’s about agency.

As I wrote in my original post about writing less code back in 2019, the developers who succeed are the ones who pause to understand, research, and think before diving into implementation. That advice hasn’t changed—but now the research phase includes co-creating with AI tools.

To Lead or Be Led

And so we return to Hamlet.

Progress will happen. The wave will come. The skull is in our hand.

The real question isn’t whether AI will build software. It’s whether you want to be someone who shapes the future or someone who waits for others to shape it for you.

To vibe or not to vibe—that remains a personal choice. But it is, undeniably, the choice of our time.

The Practical Path Forward

If you’re ready to explore vibe engineering but aren’t sure where to start:

Begin with exploration: Use AI to research unfamiliar territory before committing to an approach
Iterate openly: Treat early AI output as a draft, not a final product
Provide context: The more context you give, the better the collaboration becomes
Maintain standards: AI should amplify your craftsmanship, not replace it
Stay curious: The tools are evolving rapidly—what feels awkward today might feel natural tomorrow

The fundamentals still matter. Less code is still better code. Good architecture still beats clever hacks. Understanding the systems you build still trumps blindly accepting AI suggestions.

But now, we have a new way to apply those fundamentals—through orchestration rather than line-by-line typing.

The future belongs to those who can combine the wisdom of the old world with the capabilities of the new. Those who understand both the craft of software and the art of collaboration with intelligent systems.

The choice is yours.