The Joy of Code in the Age of Vibe Engineering

Source: Dev.to

Introduction

Programming has always appealed to me because I can get a machine to bend to my will.
The puzzle‑like pleasure of breaking a messy problem into smaller pieces, staring at a system until the shape of a bug finally reveals itself, and digging through hundreds or thousands of files to find the one thing that’s off—when it works, it gives a real sense of accomplishment, much like solving a crossword or a jigsaw puzzle.

A lot of that joy also came from how I learned to program. I’m entirely self‑taught; I never took a programming class in college that I didn’t fail. That doesn’t make me better than anyone else, but it shaped how I think. Learning outside a traditional path forced me to read a lot of other people’s code, reverse‑engineer decisions, and develop a stubborn self‑reliance. That background gave me edges and perspectives I might not otherwise have had.

Open‑source software was central to that journey. It’s how I learned, and contributing back has always mattered to me—not as virtue signaling or résumé building, but as reciprocity. I’ve benefited enormously from OSS over the years, and giving something back still matters more to me than credit ever has. Of all the things I’ve done professionally, that’s what I’m most proud of.

For a long time I half‑jokingly called myself a bare‑knuckles programmer. I’d slog through things out of stubbornness. If I wrote it, I wrote every line of it. There was no code in my projects that exceeded my own ability, even if some of it took far longer than it should have when I needed to stretch and expand my ability.

That relationship to code is changing.

From vibe coding to vibe engineering

I don’t love the term vibe coding, because it suggests you just tell an AI what you want and it spits something out. That’s not what my experience has been like at all.

What I’m doing feels more like vibe engineering.

It’s real work: planning, constraint‑setting, and taste. It’s knowing how to ask the right questions, how to push back, and how to recognize when something smells wrong. A lot of the effort goes into building a plan collaboratively, then interrogating the output:

• Why did you do it this way?
• What does this code actually mean?
• What assumptions are hiding here?

The work hasn’t disappeared—it’s moved up a level.

PAGI and the hollow aftertaste

PAGI wasn’t something I casually prompted into existence. I spent well over a year thinking about it: personal research, research with AI, reading and re‑reading existing codebases, staring at designs, backing out of approaches that didn’t feel right, and slowly converging on something I believed was worth building. By the time I started writing serious code, I’d already invested a lot of myself into the problem.

When I did build it, I vibe‑engineered essentially the entire project, including some genuinely complex areas around async code and web servers—topics I’m still not an expert in.

On one level, it was intoxicating. I produced something I’d been thinking about for a long time, in a domain I’d historically avoided. The system works. It’s real, and I think it’ll be a valuable addition to the Perl OSS ecosystem.

And yet the sense of achievement felt a little hollow. Not because it felt dishonest or unearned, but because my relationship to the code was different. Some of the code in PAGI is code I could not have written from scratch at the time I wrote it. I understand it now—deeply, in fact—because part of the vibe‑engineering process for me is reviewing everything and asking detailed, sometimes annoying questions. Still, it feels different than having typed every line myself.

In the past, there was never any code in my projects that was something I “couldn’t have done.” With PAGI, that line was crossed.

Authorship, credit, and open‑source discomfort

That crossing raises uncomfortable questions, especially in open source.

• Is this really my work?
• How should I respond to praise for the work?
• Is AI a tool, a collaborator, or something closer to ghostwriting?

What makes this tricky is that I genuinely don’t care much about credit. What I care about is contributing something useful back to a community I’ve benefited from enormously. Still, even if the ethics feel sound, there’s an internal discomfort that’s hard to ignore. Praise for cleverness or design lands oddly when you know how much of the implementation was dialogued into existence rather than hand‑forged.

I don’t have clean answers here, and I’m not sure I want to pretend that I do.

Mastery, necessity, and selective depth

Part of what complicates all this is realizing that I don’t actually need to master everything anymore.

I don’t have a professional need to be an expert in building secure, performant web servers. That’s never been a core job requirement, and it’s unlikely to become one. In that sense, this isn’t fundamentally different from how I use SQL while knowing relatively little about database internals. A big part of the reason to write PAGI is to hide a lot of the complexities of asynchronous web programming behind a higher‑level abstraction so that less knowledgeable programmers can actually use it without having to spend a lot of time mastering low‑level asynchronous primitives.

And yet, there’s still a part of me that wonders whether I would have been happier mastering those topics the old way—line by line, mistake by mistake.

That tension is real. Some of it is about craft, some about identity, and some about timing. I’m in the final stage of my professional career; I’ll likely be letting go of this work sometime in the next ten years or less. In counterpoint, I haven’t been this excited about programming since the late ’90s—and that excitement sits right next to a quiet grief for what’s changing.

When vibe engineering feels like mercy

What convinced me this isn’t a simple “AI good / AI bad” story was a very different experience.

At work, I had to translate several thousand lines of dense, tech‑debt‑laden Perl into our newer Go‑based system. It was unpleasant work—the kind of job I like the least. Lots of dead zones, historical baggage, and brittle logic.

Vibe engineering that task didn’t produce any existential angst at all. It produced relief.

The cost of getting it wrong was lower. The emotional burden was lighter. I didn’t feel like I’d lost anything meaningful by not hand‑crafting every line. That contrast made something clear: the discomfort isn’t about AI—it’s about where I derive meaning.

Thinking out loud without the paralysis

There’s another gain here that I didn’t fully appreciate at first.

Like many programmers, I can get stuck in decision paralysis, especially around architecture—a mild form of OCD, I imagine. I’ll spin on trade‑offs, worried about choosing the “wrong” direction. In the past, the cost of being wrong felt high—not just technically, but personally, because it meant committing a lot of my own effort.

Dialoguing with AI has helped break that cycle.

Talking things out—even with something that isn’t human—helps me externalize the problem. I can explore options, stress‑test ideas, and move forward with less anxiety. Because the personal cost of a wrong turn is lower, I don’t freeze as often. I make decisions knowing I can revise them without paying the same psychological toll.

That’s a different kind of joy—quieter than pride, but real.

Where joy lives now

I don’t know what a “great programmer” is anymore. I’m still proudest of my open‑source work. What feels most unquestionably mine now isn’t every line of code, but the problems I choose, the slant I put on solutions, and the insistence on doing the smallest fix that isn’t dumb and aiming for simple, understandable code and interfaces.