GoKawiilAlmost a decade ago, I wrote about Java Developer vs. Software Engineer. At the time, I didn’t realize how deeply people had tied their professional identity to Java. My goal was to distinguish between someone defined by a specific language and someone who thinks more broadly about solving problems.
The whole discourse started from one premise. Java had become the way. Many developers began thinking from Java outward. The tool became the lens through which every problem was viewed. And when a problem didn’t fit that lens, the problem was bent until it did.
I don't want to stretch that analogy too much, because AI is not just another programming language or framework. It changes the economics of writing software. Still, the old pattern is there. A tool becomes powerful, people wrap their identity around it, and then the craft gets reduced to the tool.
Now, the question is not whether AI can write code. It does. It does it better every day. The question is what kind of work comes out of that process and what happens when it enters a real codebase, with real users, real data, real compliance requirements, real incidents, and real people who have to maintain it.
That is where I see the difference between a vibe coder and a software engineer. A vibe coder is someone who wants to test an idea by generating software as a prototype. A software engineer is someone who thinks about the entire software development lifecycle. So the difference is not the tool. The difference is where the responsibility starts and where it ends.
Pretty please, can I merge?
The Wrong Metric
A lot of the discussion around vibe coding still measures the wrong thing. People show how quickly they went from idea to app. That has value, especially when the goal is to test an idea. In a software development team, someone has to review it. Someone has to understand the intention behind it. Someone has to decide whether the dependency belongs there. Someone has to check whether the test verifies behaviour. Someone has to apply schema changes. Someone has to coordinate the change between teams. Someone has to work on a rollback. Someone has to write a runbook. Someone has to answer to a page.
None of these are part of anyone's toy project. So I would measure AI-generated work by a different metric: time to safe merge. That includes reviewability, risk, test quality, ownership, rollback, and whether the author can explain the meaningful decisions in the change. If AI makes code generation cheaper but makes safe merge more expensive, the team has not gained as much as it thinks.
This is the first difference. A vibe coder measures time to first working version. A software engineer measures time to safe merge. Time to first working version is useful when the work is discovery. Time to safe merge is necessary when the work enters a shared codebase. It includes review cost, test cost, rollout cost, rollback cost, coordination cost, and future maintenance cost. That is why the demo is the wrong finish line. It only proves that something can be shown, not that it can be absorbed by a team.
... continue reading