Vibe Coding Doesn’t See The Forest

Howdy friends!

So today I ran into something while vibe coding with Claude Code that got me thinking about the bigger question everyone in tech is dancing around right now — are software engineers still necessary?

I was adding FCM push notifications to RiseOhana — a family bonding app where parents create quests for their kids, kids complete them and share updates, and the whole family celebrates together. Think habit building for families, powered by gamified parenting and quality time rewards instead of cash. Already had SignalR in there handling real-time messaging. Simple enough, right? I handed it off to Claude, let it cook, and it came back with a perfectly functional FCM implementation.

The problem? It had absolutely no idea SignalR existed.

Not because Claude forgot — it’s that vibe coding doesn’t zoom out. It saw “add FCM support” and executed on exactly that. A clean, isolated, self-contained FCM abstraction. Lovely little thing. Completely disconnected from reality.

Now I had two notification channels living parallel lives in my codebase, and suddenly I’ve got a new class of problems:

• Every time I want to send a notification, I have to remember to publish on both channels
• If I’m debugging and a message comes through, I have to figure out — did FCM send that? SignalR? Both?
• There’s no single place in the code that owns “a notification was sent”

The fun thing about vibe coding is that it’s fast. The not-fun thing is that it’s stateless about your architecture. It doesn’t ask “what already exists that this belongs to?” It just builds the thing you asked for, right next to everything else you already have.

---

The vibe coding fix: a conversation, not more code

I stopped and actually talked to Claude about the system. Both FCM and SignalR are doing the same conceptual thing — they’re observers getting notified when something happens. They’re just different delivery mechanisms. That’s the Observer pattern, and we already had half of it.

So we built a unified abstraction. One publisher interface. Two implementations underneath — one for SignalR, one for FCM. Now there’s a single place in the code where “a notification goes out” lives, and the channel is just an implementation detail.

Before:

// In feature A
await fcmService.SendAsync(userId, message);

// In feature B
await hubContext.Clients.User(userId).SendAsync("notify", message);

// Did I get both? Did I get neither? Who knows!

After:

await notifier.PublishAsync(userId, message);
// Both channels handled. One place to reason about. One place to debug.

Oh, and one more thing — after our whole design session, Claude wrapped up the conversation, summarized everything beautifully into memory… and then just sat there. Ready to move on. Didn’t touch a single file.

So I politely asked my homie to actually make the changes.

It did. We’re good now.

---

So back to the big question

Are software engineers still necessary? I think moments like this answer it pretty clearly. Claude executed the feature perfectly. What it couldn’t do was understand where that feature lived in the context of the whole system. It took an engineer to recognize that FCM and SignalR were solving the same problem, that the Observer pattern was already in play, and that the right move was unification — not addition.

AI is an incredible executor. Engineers are still the ones who understand the system holistically, recognize the patterns, and ask the questions that prevent the codebase from turning into a city without zoning laws.

The partnership is genuinely great — when you use it right.

I’ll keep sharing my journeys of figuring out what that partnership looks like in practice. And if you’ve had different experiences — times where AI got it right without the nudge, or went even further off the rails — I’m genuinely keen to hear from you. Drop it in the comments or reach out. We’re all figuring this out together.

If you enjoy reading about software gotchas and hard-won lessons, check out my post on Entity Framework migration gotchas — a different kind of rabbit hole, same amount of pain.

Happy coding friends! Keep on coding on!

---

RiseOhana is my startup — a family engagement platform built by a nerdy dad of three who spent 25 years helping machines communicate better and decided it was time to build something that helps families level up together. If that sounds like your jam, come find us at riseohana.com.