Can Vibe Coding Build Production Software Without an Engineer?

Short answer: not yet. Longer answer: an engineer's job splits in two, and a founder can already own one half.

Table of contents

• Someone asked the right question
• "The AI writes the code, so who needs an engineer?"
• The code was never the business
• Run it like an office, not a chat
• Every part of the business, on one board
• "Isn't this just bureaucracy for robots?"
• So what's the worst that can happen?
• How not to fix it
• Vibe code the work. Engineer the office.
• The founder's half

Someone asked the right question

This week someone asked on X: can vibe coding produce production-ready software without an experienced engineer?

It's the right question, and most answers argue about the wrong thing: whether the model can write the code. It can. Writing the code was never what made software production-ready.

"The AI writes the code, so who needs an engineer?"

The belief goes like this. You describe what you want, the model builds it, and the engineer becomes an expensive middleman. Just vibe it.

For a weekend project, that's true. You describe, it builds, you click around, it works. Ship it.

The model never pushes back, never asks for a raise, and never says "that's not in scope." Which, it turns out, is the whole problem.

Then someone pays for it.

The code was never the business

Think about a restaurant. Great cooks don't make a restaurant. Someone decides the menu. Someone tastes the plate before it leaves the kitchen. Someone watches what the ingredients cost. The cooks can be brilliant, and without those three jobs you're one bad night away from closing.

Vibe coding hired the cooks. It didn't hire the other three.

That's what an experienced engineer actually brings, and most of it isn't typing:

1. Deciding what's in scope. What gets built this week, and what waits.
2. Saying "not done yet". With evidence: which tests must pass, what counts as reviewed.
3. Watching the cost. Noticing when a task has eaten three times what it should.

Ask one model to do all three, in the same chat where it writes the code, and it does them the way a new hire would on day one: confidently, and with nobody checking.

Run it like an office, not a chat

This is why I'm building Code Desks, a small open-source tool that runs AI coding sessions like an office instead of one long chat.

• A desk is one real AI coding session (Claude Code, Codex or Cursor) with a job description: product manager, developer, reviewer, or whatever your office needs.
• An office is a set of desks working one project on a sprint cadence, written down in one file you can read.
• Work moves between stages through gates. A gate is a checklist with two columns, and nothing moves until both are filled.

The two columns are the trick, because one person can wear two hats:

Hat	Owns	In business terms
Owner	scope, priority, the final yes	the CEO, the product manager
Engineer	estimates, risks, tests green, evidence	the CTO

The owner decides. The engineer proves. A gate can be engineer-first: the owner's "yes" is refused until the evidence is on file. Nobody can sign off on nothing.

Every part of the business, on one board

Here's the part that matters if you're not an engineer. The office file reads like an org chart with a budget attached:

desks:
  pm:     { role: roles/pm.md,     harness: claude, budget: 10_000_000 }
  dev:    { role: roles/dev.md,    harness: claude, budget: 36_000_000 }
  review: { role: roles/review.md, harness: codex,  budget: 5_000_000 }
  launch: { role: roles/launch.md, harness: claude, budget: 4_000_000 }

• Product: the PM desk turns your idea into scoped pieces of work.
• Engineering: the dev desk builds. A review desk, running a different model, checks it.
• Growth: a launch desk writes the landing page, the docs and the announcement, in the same project and through the same gates. It's just another job description.
• Finance: every desk gets a token budget per sprint, and a meter reads what each desk actually used from the logs the sessions already write. No estimates, no guessing a price. Just a line like "the PM desk used four times its budget this sprint".

Here's the shape of what the meter prints (trimmed):

usage sprint 2 · 2026-09-22 → 2026-09-29
DESK    HARNESS  SESS  TURNS  TOTAL    BUDGET          PROJECTION
pm      claude   3     412    41.8M    418% of 10.0M   125.4M/30d
dev     claude   5     1105   132.2M   367% of 36.0M   396.6M/30d
review  cursor   2     96     n/a      no data

No dashboard, no invoice. A table that says which hire is over budget and what next month looks like if nothing changes.

That last one changes the conversation. Each desk is an investment: tokens in, work out. The meter shows what each desk cost. The board shows what it got through the gates. Where next sprint's budget goes is a business decision, and it belongs to the owner.

"Isn't this just bureaucracy for robots?"

Fair objection. If you're building a weekend toy, skip all of it.

But look at what a gate actually replaces. Not meetings. It replaces the moment an experienced engineer leans over and asks "did you actually run the tests?" The gate asks it every single time, including at 3 a.m. and on the tenth run of a Tuesday, when nobody is leaning over anything.

So what's the worst that can happen?

Without the office: the agent says it's done. The tests it ran were ones it wrote itself. (That happened to me: 16/16 green, and the one check that mattered said no.) Nobody tracked what it cost. You launch, and your first real customer finds what the tests didn't.

With the office: the same agent says it's done. The gate runs the project's real test command, it fails, and the work doesn't move. You find out on Tuesday, not from a customer.

How not to fix it

• Hire an engineer to read every line. It works for one project. It doesn't keep up with how fast agents write.
• Use a bigger model. A smarter model writes more code, faster. It doesn't decide what's in scope or what counts as done.
• Write a longer prompt. A prompt is a suggestion the agent weighs against its goal. A gate isn't.

Vibe code the work. Engineer the office.

So, can vibe coding produce production-ready software without an experienced engineer?

Not yet. Someone still has to decide what "done" means and write the checks that prove it. That's engineering judgment, and the model shouldn't be the one grading its own work.

But the rest of the job (the scoping, the handoffs, the "not yet", the budget) can be written down once and run every sprint.

Vibe code the work. Engineer the office.

The founder's half

If you're a founder or a product manager building with AI, you don't have to become an engineer. You have to run the office: hire the desks, set their budgets, decide what "done" means, and keep the final yes.

That's the half you can own today. Borrow the other half, the checks, from an engineer once, and let the gates ask the question every time after that.

Code Desks is early (v0, MIT): github.com/azank1/code-desk-cli

What's the first job you'd give a desk that isn't writing code?

---

Related: Can AI Trust Its Gut?, on when an agent's fast call can be trusted, and Vibe engineering with Opus 5.5? Route by the feedback, on picking the model by what comes back when it acts.