Vibe coding brought back my love for programming

Estimated reading time: 4 minutes

What this new approach to software development has taught me about the future of staff-level engineering as a distinguished engineer.

One month ago, I pushed a single prompt into my AI coding agent:

“Update this library to use React 19. The library’s core functionality relies on internal React APIs that are no longer accessible in the latest version of React. To make this library compatible with React 19, a significant refactor of its core logic would be required.”

About 10 minutes later, the AI agent had refactored the code to use the new APIs, updated the README, and added additional tests. With just one prompt, it handled the work autonomously, turning a task that normally takes a weekend into a single review session. It was a pretty magical experience. I felt I had experienced what AI researcher Andrej Karpathy coined somewhat playfully as “vibe coding.” 

For me, it felt like stepping back into my early dev days – late nights, rapid iteration, the thrill of building something real. But unlike then, I now have decades of engineering judgment guiding when and how to apply this new mode of work.

Building castles again

When I’m vibe coding on late-night concepts, sometimes the AI agent nails it. Often it doesn’t. I often end up with a few throwaway scripts, a surprisingly useful internal dashboard, and more importantly, something even more valuable: a reminder that I love building things.

As a distinguished engineer, that feeling of being in a creative flow often gets buried under architecture reviews, strategic planning, and org-wide initiatives. The deeper you go into leadership, the less time you have to touch code. 

Frederick Brooks once likened coding to “building castles in the air.” Vibe coding gave me that magical feeling back. The asynchronous nature of vibe coding makes it accessible. I’ll queue up a task, head into a meeting, and return to find a fully-formed implementation ready for review or integration.

But I also saw the risks up close. Vibe coding can be wildly productive – and deeply reckless. When used by the right developer, at the right moment, it’s a force multiplier. Used poorly, it’s a shortcut to technical debt.

Why this matters for staff+ engineers

As someone operating at a staff+ level, your time is better spent on decisions that drive clarity, reduce risk, and elevate system design – not fighting with things like CSS margins. This is why vibe coding, when used intentionally, can accelerate prototyping, augment your learning, and unstick you when the cognitive cost of context switching is high. Vibe coding, when used intentionally, enables us to:

• Rapidly validate an architectural direction
• Unblock team momentum with quick scripts 
• Prototype experiments without dragging down sprint velocity

I’ve used vibe coding to explore low-risk features, validate spike paths, and test unfamiliar APIs. However, this isn’t about taking AI output at face value. Every change deserves scrutiny. Every generated function should be understood. 

The hidden risks of vibe coding 

It’s tempting to celebrate vibe coding as the future of software development. But used without guardrails, it can become a liability.

When vibe coding, I’ve seen AI quietly introduce deprecated libraries, duplicate code, and introduce security flaws. AI doesn’t know my edge cases. It doesn’t care about my application uptime. 

I treat vibe coding as a tool – I pair it with structured learning. I use it to build momentum, not to bypass fundamentals.

How to apply vibe coding correctly

There’s a time and place to vibe code. I’ve found it successful when using it in the following ways:

• Prototyping ideas – When I need to visualize a solution fast, a working prototype speaks louder than any slide deck.
• Learning new technologies – I treat AI as an interactive explainer. Ask questions. Follow the logic.
• Automating boilerplate – I let AI handle repetitive scaffolding when exploring new SDKs or APIs.
• Writing utility scripts and internal tools – I’ve used it from log parsing to batch API calls, vibe coding does great at small automations.
• Experimenting in low-risk environments – I’m using it for side projects as the perfect sandbox.

Operational guardrails and tips

I truly believe you can embrace vibe coding without sacrificing good engineering practices. Here are some of the ways I keep it productive:

• Treat the AI like a junior pair programmer – Never merge code without a human sanity check.
• Enforce continuous integration (CI) gates – Tests, linting, secret scans, and static analysis must pass before merging.
• Write explicit rules – Include specific directives like “reuse existing tests” or “don’t modify infrastructure.” I document the AI conventions and architectural patterns clearly, considering it as onboarding material for my AI co-pilot.
• Orchestrate in small, testable units – AI coding agents perform best when scoped narrowly.
• Adopt an iterative workflow – Start a new chat for major tasks to avoid context overload. Feed in the rules and specs at the beginning of each session. If the session feels sluggish or starts hallucinating, it’s time to reset – whether that’s undoing AI’s changes or starting a new prompt/chat interaction.

New York • Oct 15 & 16, 2025

Full agendas for LeadDev’s New York events are up! 🎉

See who’s speaking

Final thoughts

Over the past few months, vibe coding has helped me rediscover the joy of building. Prototyping is fast. Exploration feels lighter. But what’s become increasingly clear is this: AI won’t simplify our projects. It will shift the skill set required to navigate them. 

The key to thriving in this AI-driven landscape will be adaptability and communication. Tomorrow’s staff+ engineers won’t just write great code; they’ll pivot with each new model release or policy change and, just as critically, articulate those pivots to teammates and stakeholders. They’ll design resilient systems, guardrails, and workflows that can include, without being derailed by, AI coding agents.