Vibe Coding Vs Agentic Engineering: Where I Draw The Line Susiloharjo

I read something last week that stopped me mid-scroll: vibe coding and agentic engineering are getting closer than he’d like — and he’s not comfortable with it.

I get it. I use Claude Code almost every day now. Not as a novelty. As my actual workflow. And I’ve noticed the same blurring he’s talking about. I’ve written before about my five AI coding personas — the different hats I wear when working with AI. But this is about something deeper: where does my judgment end and the AI’s begins?

The Two Modes I Live In

When I open Claude Code in the morning, I’m always in one of two modes.

Mode 1: “Just do it.” This is when I’m refactoring something boring — renaming 40 variables across an Angular module, or converting a bunch of raw SQL queries to use parameterized inputs. I describe what I want, Claude writes the diff, I glance at it, accept. Ten minutes of work in 30 seconds. This is vibe coding. I’m steering with intent but not reading every line.

Mode 2: “Show your work.” This is for anything touching production data, auth logic, or PostgreSQL migrations. I ask Claude to explain its reasoning first. I read the diff carefully. Sometimes I reject three versions before accepting one. This is agentic engineering — the AI is a tool I control, not a collaborator I trust.

The line between them isn’t technical. It’s *consequence*. If a bug here means a coworker’s dashboard shows wrong numbers during the morning meeting, I’m in Mode 2. If it means a console.log statement I forgot to remove, Mode 1.

Where the Blur Happens

The problem Willison flagged is real. Mode 1 creeps into Mode 2 territory without you noticing.

Last month I was building a data export feature for our ERP. Nothing critical — just CSV generation. I was in full vibe mode. Claude wrote the export logic, I accepted it, shipped it. A week later someone noticed negative values in the “total hours” column. Turns out Claude had reversed a subtraction order in one edge case. I didn’t catch it because I wasn’t reading carefully enough.

The bug itself was a 2-line fix. But it made me realize: I had vibe-coded something that touched actual financial data. The consequence was small, but the pattern was bad.

My Personal Rules Now

After that incident, I set some hard rules for myself:

1. Any code touching money, auth, or data integrity → Mode 2. No exceptions. Read every diff. Ask Claude to explain its reasoning. Run the tests yourself.

2. Anything I’ve written 20+ times before → Mode 1. Boilerplate, CRUD endpoints, form validation. I know what correct looks like, so I can spot wrong in 2 seconds.

3. New territory → Mode 2. If Claude is generating something I’ve never built before (a new WebSocket handler, a PostGIS query), I stay in the driver’s seat. I need to understand the code well enough to debug it at 11pm when it breaks.

4. Friday afternoon → Mode 1 only. I’m tired, I’m prone to rubber-stamping diffs. If it can’t be vibe-coded, it waits until Monday.

The Verdict

Vibe coding and agentic engineering aren’t two different camps — they’re two modes on the same spectrum, and I slide between them multiple times a day. The skill isn’t picking one. It’s knowing *when* to switch.

If you’re using Claude Code or Cursor daily, pay attention to your own acceptance speed. Are you reading diffs less carefully than you were a month ago? Are you shipping code you don’t fully understand? That’s the blur Willison warned about.

My rule is simple: the higher the consequence of failure, the more I act like an engineer and less like a vibe coder. Everything else is just keystrokes.

Discover more from Susiloharjo

Subscribe to get the latest posts sent to your email.