Without Vibe Coding, What Am I?

That afternoon, I had three windows open.

One was running unit tests. The Agent said, “Estimated time: eight minutes.” One was refactoring the module I’d already changed three times. The Agent said, “I’m analyzing dependencies.” The third was reformatting logs. The Agent said, “Okay, I’ll unify the timestamp format.”

I sat in front of the screen with nothing to do.

Scrolled my phone four times. Stood up, got a glass of water. When I came back, I glanced over – all three tasks showed “Completed” or “Ready for review.” I didn’t read the code. I clicked “Create pull request” first. The click was light. The left mouse button, a soft tick. Later I thought – that tick might not have been that different from the sound of pressing a detonator on a construction site.

You asked what I am without Vibe Coding. I’ll tell you what I became with it.

Before, when I fixed a concurrency bug, I’d sit with the call stack for two hours.

There were no other threads in my head. Just the road between one lock and the next. That road started at the entry function, cut through three middleware layers, and buried the trap in an unremarkable callback. I knew what it looked like, not from documentation, but from breakpoints. I’d stopped there. Many times. Every time I stopped, my mental structure gained one more line.

It was slow at first. Just scattered information. Which scope a variable fell out of. Which layer swallowed the exception. Which field that weird “null” in the logs actually came from. As the context filled in, the dots connected themselves. Once they did, speed followed. After that, many decisions didn’t need repeated lookups. Flow state just arrived.

What does flow feel like? You don’t remember time. You only remember the road.

Now?

I see a complex problem. My fingers move before my brain. Ctrl+C, select the stack trace. Ctrl+V, send to Agent. “Analyze the possible causes of this exception.” Send. Wait.

While the Agent runs, I switch out to reply to messages. By the time I’m done, it’s finished. Glance at the summary: “Looks like a null pointer. Suggest checking line 47.”

“Looks like.”

That phrase is now the most frequent one in my codebase. Looks right. Looks reasonable. Looks like it passes. I don’t know if it’s actually right. I only know the tests are green. And when the tests are green, I hit merge.

Later I noticed something: I hadn’t stayed on a single problem for more than half an hour in a long time. Not because I didn’t have time. Because I didn’t have patience. Ten minutes into a call stack, a voice in my head said, “Just send it to the Agent.” Two failed debugging attempts, and my fingers automatically switched to the chat box to rephrase the prompt. The design wasn’t even settled, and code was already generated.

Slow thinking gets harder and harder to sustain.

Complex engineering problems depend on exactly that. Concurrency states. Data consistency. Failure recovery. Performance bottlenecks. These are rarely solved through a few rounds of Q&A. They require you to stay in the same context long enough for the local details to grow bones and veins.

Right now I only have meat. A pile of raw meat. The Agent diced it, stacked it neatly – but it’s not attached to me.

Running out of tokens causes anxiety. That’s normal.

Having tokens left over also causes anxiety. That’s a little strange.

I bought the subscription. At the end of the month, seeing eight thousand tokens still unused gave me a sense of waste. Waste is shameful. So before I left my desk, I’d always cram in one more task. Before a meeting, I’d have the Agent run a round of regression tests. Before lunch, I’d have it tidy up the interface comments.

The worst was before bed.

Lying there, something suddenly hits me: “That module’s exception handling still isn’t unified.” Roll over, grab the phone, open the chat box. “Help me unify the exception handling in module X. Use custom error classes. I’ll review it tomorrow morning.”

Send. Lock the screen. Close my eyes. My brain keeps spinning. Will it mix up the error types? Will it introduce new dependencies? How many changes will I have to review tomorrow? Tomorrow morning...

Can’t sleep.

This anxiety slowly reshapes task priorities. Things that didn’t need to be done right now got pushed in because the Agent happened to be idle. Requirements not yet clear – “let’s build a version and see.” Code that was still maintainable – “let the Agent refactor it first.” Tests already sufficient – “adding a few dozen more cases can’t hurt.”

The Agent gets busy. My review queue piles up.

The next morning I open my laptop. All the tasks show “Completed.” Looks like I gained a night of free productivity. Only on closer inspection do I realize: every result requires reloading the context, every one needs boundary checking. After the AI pulls an all-nighter, I start my overtime – reviewing.

What’s worse – waiting for results consumes attention too. I’ve already left my desk, but my mind is still hanging on that task. Did it finish? Did it fail? How many changes to look at tomorrow? Rest time turns into a long asynchronous wait. I didn’t clock out. I just switched to a different way of being on call.

Monday’s PR.

The Agent changed the interface signature, added integration tests, refactored three callers. All tests green. I sat in front of the screen. Three files of diffs. Each looked reasonable.

But it took me an hour to confirm – that “reasonable-looking” interface abstraction had already been implemented once in another module. Two sets of logic, different by two characters. Two characters.

That hour was the bill.

The client doesn’t pay for those thousand lines of code. The client pays for this one hour of my judgment. Judgment is sold by the hour. I didn’t used to understand this. I thought code was sold by the line. Now I know: generating a line of code takes two seconds. Deciding whether that line should exist takes forty minutes.

What’s more exhausting – this judgment often has no standard answer.

The Agent’s code has good naming. Complete structure. Full comments. Tests too. Each segment makes sense in isolation. But placed back in the whole system, it often feels superfluous. A boundary condition expanded into a generic framework. A local fix introducing a new middleware layer. Three superficially similar flows forcibly abstracted together.

The code runs. Tests pass. But maintenance cost quietly rises.

I need to explain why a piece of “correct” code doesn’t belong in the current system. Explaining is more tiring than writing. After repeating this a few times, I started avoiding it. Since the tests passed – merge it first. If something breaks, have the Agent fix it. Next time, the Agent expands further on the structure it generated last time. More code. Less understanding.

Now there’s a lot in the codebase that nobody fully understands. Written by me. Generated by the Agent. I’m not sure who to attribute it to.

One day I did something stupid.

I rolled back the entire “elegant refactoring” the Agent had generated. Replaced it with the old two hundred lines of handwritten code – inelegant, but everyone knew exactly how it had died.

Then I stared at the rollback log for a long time.

Later I thought – if one day my position is replaced, it won’t be by the person who knows how to use Agents. It’ll be by the person who dares to delete Agent code. People who dare to delete are more expensive. Because before deleting, they have to read. To understand. To confirm nothing breaks after deletion.

Fewer and fewer people can read.

Not because they’re not smart. Because they don’t look. The Agent looked for them, then gave a summary. Summaries can be read quickly. But summaries don’t include those “failures, experiments, and corrections.” The process of writing code by hand is the process of building cognition. To implement a feature, I need to find the entry point, understand dependencies, handle compilation errors, observe test failures, confirm how data flows through the entire chain. After implementation, I have my own judgment about that part of the system.

Vibe Coding skips all of this.

The Agent tells me which files were changed, what approach was used, what the test results were. I quickly get a complete explanation – but I didn’t go through those failures, experiments, and corrections. Between knowing the result and mastering the system, there’s a long distance.

This gap doesn’t show up easily in daily iteration. The Agent can keep modifying. Features can keep shipping. Until an incident happens. Or a complex refactoring. Or a performance regression. Then the team needs to locate root cause under pressure. The deferred understanding cost arrives all at once. Everyone has participated in developing the system. Ask about the critical path – they can only describe pieces. Push further – how does the exception propagate? How does data recover? Where’s the capacity boundary? The answer gradually becomes: “Let the Agent analyze it.”

The tools are still there. Work can continue. But the sense of control over the system is fading.

Someone asked me, who’s the authority in this field now.

A high-star GitHub AI project author posted a tweet. Screenshot with the caption: “I built a microservice with three Agents in ten minutes – auth, database, cache, message queue.” Thousands of likes. Comments full of “Amazing” and “Share the prompt.”

An old engineer I know – he hasn’t written open source in a long time. Last month, a P0 incident. Every Agent failed to analyze it – the error in the logs was a special behavior from a specific driver version, not documented anywhere. He closed every dialog box on his screen. Opened the debugger. Followed it for two hours.

In the end, he submitted one line of change.

One line.

Authority isn’t necessarily the person who writes the most. Authority might be the person who, while everyone else is generating, is willing to stop and read. That might be an old standard. But I can’t think of a new one to replace it. The high-star project author and the one-line-change author might be different kinds of authority. The first proves “what can be generated.” The second proves “what can be judged.” If I could only put one in my team, I know my answer. But it doesn’t sound good to say out loud, so I’ll leave it there.

I still use Agents every day.

But I started a practice.

At least once a day, when I run into a problem, I don’t copy it to AI first. I read five minutes of code. Sometimes I understand it. Sometimes I don’t. When I don’t, I send it to the AI – but at least I know what I don’t understand.

“Five minutes of reading” sounds ridiculous. It used to be measured in hours. But five minutes is better than zero. Five minutes can tell you which part of the code you don’t understand. Knowing what you don’t know – that thing is precious now. Most of the time, I don’t even know whether I understand or not.

If one day I lose this habit too.

I don’t know if I still count as a programmer.

But if you ask me what I am without Vibe Coding – maybe I’m someone who’s still willing to read five minutes of code.

Three in the morning. An alert goes off. The phone lights up. You get up, open the laptop. Logs are scrolling. The stack trace is long. There’s no Agent beside you. Or the Agent can’t handle it, because the error is too obscure – not in the training data.

What do you do?

Can you still read code for an hour straight? Can you explain a single change without a summary? Can you independently judge whether an abstraction should exist? When something breaks in production, do you have the complete execution path in your head?

These questions worry me more than token usage ever did.

I used to get tired from coding – tired from implementing. Now I get tired from continuously receiving, continuously judging, continuously reviewing. The machine keeps outputting. My brain never really clocks out. But at least I’m still looking. Still reading. Still distinguishing that gap between “looks right” and “is right.”

That thing used to be called “craft.”

I don’t know what to call it now.

But if you still have it – don’t lose it. What’s valuable isn’t the code. It’s the ability to say no to code.