What is a Vibe SWE

A Vibe SWE is a software engineer who is AI-native from day one and still owns the ship. The models draft. The human sets intent, reviews the diff, takes the pager. That is the whole definition, and every word of it is load-bearing.

Vibe SWE is a subdomain of vibe engineering — not a rival to it. Simon Willison's framing of vibe engineering describes the senior, accountable practice: tests, evals, reviews, production discipline, an engineer who could have written the code by hand and chose not to. Vibe SWE is the seat you sit in on the way there, and the seat most working engineers occupy today.

Vibe coding → Vibe SWE → vibe engineering

Vibe coding is prompt and hope. You describe a thing, accept what appears, and don't read it closely. It is genuinely useful for weekend software, throwaway scripts, and learning what a model can do. It stops being useful the moment someone else depends on the output.

Vibe engineering is the far end: accountable senior practice, at scale, under load, with evidence. Test suites the model runs against. Evals that catch regressions a human never would. Someone who owns the outcome in a postmortem.

Vibe SWE is the middle, and the middle is where the volume is. You generate most of your code. You read all of the code you ship. You can explain every decision in the diff, and you can name the ones you delegated on purpose. You are not pretending the models didn't write it, and you are not pretending that absolves you.

Past craft still counts

The parts of the job that got harder to fake are the parts that were always the job. Taste: knowing which of four working implementations is the one you want to maintain. Judgment: knowing when the model's confident answer is confidently wrong. Ownership: being the name attached to the thing when it breaks at 2am. Clear communication: turning a vague stakeholder request into a spec a model can actually execute.

None of that is nostalgia. Generation is cheap now, which means the scarce skill moved upstream to deciding what deserves to exist and downstream to verifying it does what you claimed. Both ends are human.

The new stack of the job

What is genuinely new is the load. You are running several tools at once — an agent in the terminal, an editor that completes whole functions, a model that reviews the PR — and each one has different failure modes you have to hold in your head. You are absorbing stakeholder requests at a speed that used to be throttled by how fast you could type. And you are shipping code you didn't personally write into an environment where a leaked key or an unsanitized input is your problem, not the model's.

So security stops being a later ticket. Review stops being a formality. Proof of ship — a test, an eval, a screenshot, a user who used it — becomes the artifact that separates a Vibe SWE from someone who pasted a plausible answer into main.

Models as senior collaborators

The most useful mental model: treat the model like a very fast, very well-read senior engineer with no context on your business and no stake in the outcome. You would brief that person before handing them a ticket. You would read their PR. You would not let them decide the product.

That framing kills both bad habits at once. It stops you from underusing the model — a senior collaborator can take a real chunk of work — and it stops you from over-trusting it, because no one ships a senior's first draft unread.

The loop

Build: state the outcome and the constraints, then let the model draft. Ship: small, reversible, visible, with evidence. Learn: read what actually happened and change your defaults. Then go again. Everything else on this site is detail hanging off those three words.

Build. Ship. Learn.