I Ship Production Software Without an Engineering Title: The Claude Code Operator Reality in India

I do not have an engineering job title. I have never cleared a FAANG loop or owned a squad. What I have is a single Linux box, a Claude Code setup I treat like an operating system, and more than a dozen production services that real users hit every day. This site you are reading runs on that setup. So does my paper-and-jobs property, a clutch of trading bots, and the backends behind all of them.

The lazy headline is "non-engineers are vibe-coding to prod and it is chaos." The honest version is narrower and more useful: a non-engineer can ship serious software to production if, and only if, the discipline is wired into the process and not left to willpower. The model that ships is not "ask the AI, copy the diff, push." It is one orchestrator that holds the plan and a team of subagents that execute under hard gates. Everything below is what I actually run, not a summary of someone else's pricing page.

The operating model: orchestrator plus subagents, not a single chatbot

The mistake most people make is treating Claude Code as one chat window where you paste a request and pray. That breaks the moment a change spans more than two files, because a single agent loses the plan while it is busy writing code.

The model that holds up is delegation. Opus sits as the orchestrator. It owns the architecture, the plan, and the final call on whether something is done. It does not write most of the code itself. It spawns typed subagents for the actual work: a code-reviewer to audit a diff, a security-reviewer when I am poking at anything that touches auth or user input, a test-runner to actually run the suite instead of guessing. The orchestrator briefs each subagent with everything it needs, collects the verdicts, folds in the findings, and only then ships.

This is not a stylistic preference. A read-only review agent has caught real bugs in my own releases that the building agent was blind to, because the reviewer was not invested in its own code being correct. The integration glue, reconciling what the swarm produced, is the orchestrator's job and nobody else's. When I let the orchestrator quietly absorb the execution instead of delegating it, the work gets worse and the plan drifts. The split is the whole point.

For a non-engineer this matters more, not less. I cannot eyeball a React reducer and know it is wrong. So I do not rely on eyeballing. I rely on a reviewer agent whose entire job is to find the thing I would miss, and a test-runner that proves behaviour instead of asserting it.

The discipline that makes it safe

Speed without gates is just a faster way to take prod down. My setup runs on one non-negotiable rule that overrides everything else: the agent is responsible for the outcome, so it does not get to make mistakes through laziness. Concretely, that rule decomposes into a handful of hard gates that fire on every meaningful change.

• Verify before claiming done. "I wrote the fix" is not "done." Done means the build passed, the page actually rendered, the endpoint actually returned what it should. An agent that says "this should work" without proof has not finished the task, it has guessed.
• Snapshot before destructive ops. Anything that deletes, drops, or overwrites gets a restore point first. A free box is something I should be able to lose without flinching, and the same goes for any irreversible command.
• Refuse the unsafe shortcut. --no-verify skips the pre-commit hooks. --force rewrites history and stomps other work. git reset --hard origin throws away local state. My setup refuses all of them by policy, even after I have said a general "ok." A blanket yes is not authorisation to bypass safety.
• Explicit confirmation for irreversible actions, every time. Trust speeds up the reversible work. It never short-circuits the gate on the destructive work.

These are enforced, not remembered. The dangerous commands sit on a deny-list in the harness config, so an agent cannot quietly run them even if it wanted to. A deny-list is the difference between a guardrail and a good intention. A good intention fails at 2 AM on the fifth iteration of a stubborn bug. A deny-list does not get tired.

The real stack

There is no Vercel here, no Supabase, no Firebase, no managed-everything bill that balloons the month a project gets traffic. The stack is deliberately boring and self-hosted, because boring is what survives.

• Compute is one Oracle Always Free ARM box: four cores, 24 GB RAM, zero rupees a month.
• Coolify is the self-hosted PaaS control plane. Every app deploys from a Git push, no manual server fiddling.
• PocketBase is the backend, one instance per project, each on its own subdomain. Auth, database, and file storage in a single Go binary on top of SQLite. No separate auth service to wire up.
• Cloudflare Tunnel fronts everything, so the VM has zero open ingress ports and no public IP to probe.
• Litestream streams each PocketBase SQLite file to Cloudflare R2 continuously, so a dead instance is a restore, not a loss.
• Content frontends like this one are statically exported and served from Cloudflare Pages. This site is Next.js 16 in static-export mode. A push to main triggers a GitHub Actions job that builds, deploys to Pages, and pings the search engines, with no human in the deploy path.

I scaffold and deploy new full-stack properties with a CLI of my own that wraps this stack end to end, so a fresh site goes from nothing to live behind a tunnel in minutes instead of a weekend. The point is not the specific tools. It is that the whole thing is free or self-hosted first, and only goes paid when a project earns money and explicitly needs it.

Where it actually bites a non-engineer in India

This is the part the hype skips. The model works, but it is not magic, and these are the failure modes that have actually cost me time.

Agents manufacture specifics. This is the most dangerous one, and it is the reason every piece of content on my sites runs through a verification gate before it goes live. When a primary source is unavailable or bot-blocked, a content agent will happily invent a plausible statistic, a date, a percentage, or a named anecdote and assert it as fact. On a heavily-trafficked site, invented facts are a trust time bomb for both readers and search ranking. The fix is a gate that strips any specific claim that cannot be traced to a real source. Most content farms cannot verify at scale. Refusing to publish the unverifiable is a moat, not a constraint.

The framework you trained on is not the framework in front of you. Claude Code's training is broad, and broad knowledge lies confidently about specifics. Next.js 16 broke conventions an agent expects from earlier versions: route params arrive as a promise you must await, every dynamic route in static-export mode needs explicit static-params generation, and the standard image component does not play with external URLs under static export. An agent that writes the "obvious" idiomatic code ships a broken build. The fix is to point it at the actual installed docs and treat those as authoritative over its memory.

State, async, and security are where confident code goes wrong. Presentational edits are low-risk: copy, spacing, a colour token. The breakage clusters around anything that touches state, async flows, or a security boundary. Unsanitised HTML rendered straight into the page is the classic one, a real cross-site-scripting hole dressed up as a harmless tooltip. This is precisely why the security-reviewer subagent exists and why those changes never skip review.

The plumbing has its own traps. A containerised tunnel cannot reach a bare-metal service through localhost, because inside the container localhost is the container. You address the host through the Docker bridge gateway instead. That one fact costs an evening the first time it bites, and no amount of model intelligence substitutes for having hit it once.

The honest trade-off

What I gain is leverage that should not be possible for one person without a team. I ship to production daily, across multiple properties, with reviews and tests that a solo operator could never run by hand at this pace. The orchestration-and-gates discipline below is also exactly what I look for when hiring, and it sits near the top of the AI skills that actually get you hired in India in 2026. What I give up is the comfortable illusion that the AI has it handled. It does not. The orchestrator-plus-subagents model and the hard gates are not bureaucracy I tolerate. They are the only reason a person without an engineering title can put real software in front of real users and sleep at night.

Quick takeaways

• The model that ships is one orchestrator holding the plan plus typed subagents executing, not a single chat window. A read-only reviewer agent catches what the building agent cannot see.
• Wire the discipline into the process: verify before claiming done, snapshot before destructive ops, and refuse --no-verify and --force by policy. Enforce it with a deny-list, not willpower.
• Run a boring, self-hosted stack: Coolify and PocketBase on one Oracle ARM box, Cloudflare Tunnel in front, Litestream to R2, static frontends on Cloudflare Pages.
• Agents fabricate specifics when sources are missing. A verification gate that strips unverifiable claims is a moat, especially for content sites in India.
• The framework in front of you is not the one the model trained on. Point agents at the installed docs, and never let state, async, or security changes skip a reviewer.

Related

• Claude Code subagents: the fork flag for parallel agents
• AI skills that actually get you hired in India in 2026
• Coolify on Oracle ARM, the full walkthrough
• Litestream to Cloudflare R2 disaster recovery for SQLite