Vibe Coder vs Software Engineer | Yusuf Aytas

Almost 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.

Output Is Not Progress

AI-assisted code should be better, not bigger. If the tool lets you generate more, the human has to constrain more. Otherwise you are not saving work. You are moving it downstream, where maintenance becomes someone else's chore. AI-assisted code cannot be held to a different standard. It has to meet the same bar as code written by hand. So it should be narrow. It should have one reason to exist. It should not include unrelated cleanup. It should not reformat half the file because the model felt like it. It should not add a package without a clear explanation.

If the change is large because the model generated too much, split it. I've experienced this a lot. It happily creates so many boilerplate for a thing that you can write in ten lines. So, if the author cannot explain why each meaningful file changed, it is not ready. That is basic ownership.

The second difference is the unit of work. A vibe coder treats generated output as progress. A software engineer treats any change as the unit of responsibility. Generated output can be large, messy, and temporary. A real change management cannot be that casual. It has to be narrow enough to review, explainable enough to trust, and bounded enough to merge without dragging half the system with it. This is where speed either becomes useful or turns into review debt.

AI Cannot Take the Blame

Reviewing generated code is not the same as reviewing normal code. When a human writes code, there is usually a decision trail. It might be flawed, but at least there is a person who can explain the path. You can ask why they used that abstraction, why they put the rule there, why they chose that package, why they made the test look that way.

With AI-generated code, some of those decisions are not decisions. They are completions. If the author has not...