Vibe Coding: I Have Not Written a Line of Code in Months. How I Orchestrate AI Agents Around the Clock

Vibe coding in a working developer’s day: I have not written a line of code myself in months. Instead I keep AI coding agents running, with loops, a phone hotspot, and a laptop in the car, the garden, and on walks.

I have not typed productive code in months. No function, no refactor, no CSS fix I wrote by hand. What I do all day: start agents, feed them, stop them, restart them, run them in parallel, and keep sharpening the system that steers them.

That can sound like a pitch. It is my job as a software developer in 2026, and it looks stranger than I expected two years ago. I haul a laptop almost everywhere. The phone hotspot is on more often than not. The machine sits in the car, stands in the garden, comes along on a walk. I am not trying to “work from anywhere.” The agents are just not supposed to fall asleep.

This guide explains what vibe coding actually is in production, how AI agent orchestration replaced typing as the job, what agent loops are, how to build them, and why an AI-first development workflow suddenly sounds like batteries, mobile data, and a backpack.

What is vibe coding?

Vibe coding is software development where you supply the intent and a coding agent writes the code. You describe the goal, the constraints, the style. The agent reads the repo, edits files, runs tests, commits. You steer whether the direction is right.

Andrej Karpathy popularized the phrase in 2025: you stay in the flow, you vibe with the model, you stop placing every semicolon yourself. Plenty of people treated that as a toy. For me it became the default production workflow, not a demo.

Vibe coding is also not “ChatGPT, write me a function.” That is pair programming with a clipboard. Real agentic coding means the agent has tools. It can read and write files, run terminal commands, open a browser, launch subagents, set loops, check CI. You are no longer glued to the keyboard. You are conducting what happens.

Three stages I actually went through:

1. Autocomplete: Tab, Copilot, a few lines of head start. You still write almost everything.
2. Chat coding: You paste errors into a chat, get a patch, drop it in. You still own the diff by hand.
3. Agent orchestration: You give a goal, the agent works for minutes or hours. You review outcomes, not keystrokes.

At stage 3, “I program” becomes a sloppy description. I orchestrate AI coding agents. The code still ships. It just does not come from my fingers.

I have not written a line of code myself in months

I mean that literally, not “almost none” and not “only the gnarly bits.” For months I have not personally typed a line in a production repo. No 11 p.m. hotfix I “just do myself because it is faster.” That is no longer faster.

The agent knows the repo better than my working memory. It reads the tests, the neighboring modules, recent commits, the rules, the skills. If I start typing, I am the slowest part of the pipeline. I also introduce inconsistency: different formatting, a missed edge case, a fix without a test.

What I still do, and this is the actual job now:

• Write goals an agent cannot guess
• Set priorities when three agents finish at once
• Say no when a solution is elegant and strategically wrong
• Tighten constraints: no scope creep, no new dependency, keep it idempotent
• Check results: diff, tests, live page, SEO, security
• Improve the system that steers the agents

That is AI development as daily work, not an experiment. It feels like being a lead without a junior waiting for review. The junior starts immediately, works at night, and keeps going while I walk the block, as long as the laptop has power and the phone hotspot stays on.

The psychological trap: you feel idle because you are not typing. For years productivity meant lines, commits, IDE flow. Now it is clear briefs, running loops, clean handoffs. If you do not reframe that, you open the IDE “just for a second” at night and wreck the flow the agent just built.

The always-on day: laptop in the car, hotspot on the phone, agent in the garden

What LinkedIn posts about an AI coding workflow usually skip: agents need a session. A session needs a machine. A machine needs power, network, and someone who does not slam the lid like it is still 2019.

That is why I carry the laptop almost all the time. Not as a prop, as a runtime. The computer is less “my workstation” than a small server I haul around so the agents do not die.

Why the agent dies when the laptop sleeps

A coding agent in Cursor (or a similar agent IDE) lives in a session. Terminals run. Watchers run. Loops wait for a wake signal. When the Mac sleeps, that is gone: no shell tick, no CI check, no “continue when the pipeline is green.”

So the setup is pretty unromantic:

• Lid often open, or configured so sleep does not kill everything immediately
• Network always there: Wi-Fi at home, almost always a phone hotspot on the road
• Power always in view: power bank, car charger, garden outlet, cable mess
• Laptop in the car: not to work from the passenger seat, but so the session does not drop between appointments
• Laptop in the garden: the agent runs, I am outside, I glance at the diff every few minutes instead of an empty file
• Laptop on a walk: sounds ridiculous until you notice a 40-minute loop finishes exactly when you would otherwise have gone “briefly offline”

I walk around with a backpack that keeps agents alive. That is what always-on AI coding agents look like in practice. Anyone selling vibe coding as “relax and prompt” either runs short sessions or leaves out the ops.

The hotspot is production infrastructure

The hotspot is no longer a fallback. It is part of the development stack. No network means no model, no tool call, no browser check, no deploy status. The bottleneck is rarely “can the agent do this?” More often: does this thing have LTE right now, or did the session choke in a dead zone?

What I learned:

• Turn the hotspot on before the agent hangs, not after
• Phone battery is suddenly as project-critical as the laptop battery
• Short dropouts are fine. Long ones are not, because event-driven loops miss the tick
• Public Wi-Fi is a bad deal for agent sessions with repo access. A hotspot is more controllable

This is the sentence I did not expect when I became a software developer: My job depends on a phone hotspot staying on so an agent can keep refactoring in the garden.

What agent loops are and why nothing stays running without them

A chat is linear: you write, the agent answers, done. An agent loop is an alarm clock for the session. After an interval or an event, the agent wakes and runs the same brief (or a variant) again.

Without a loop, vibe coding stays a conversation. With a loop, it becomes a process. The difference is roughly “I keep refreshing to see if deploy finished” versus “a watcher fires, and the agent acts.”

Loops are the mechanism behind keeping AI agents running continuously. Not magic, just a timer, a sentinel line in the shell, and a prompt that executes again on each tick.

Three loop types I actually use

The fixed loop is the on-ramp. The event loop is where you actually win time. Dynamic mode helps when the agent can judge: thirty seconds from now is pointless, eight minutes from now is worth it.

A loop is not a second developer. It is a heartbeat. If the prompt is weak, you get the same weak heartbeat every five minutes. That is why “build the loop” is always followed by “harden the prompt.”

How to build agent loops (step by step)

The setup below is what I use in Cursor. The idea travels to other agent IDEs: a background shell that ticks, output that wakes the agent, a prompt that says what to do next.

Step 1: Make the agent able to work before you set a loop

A loop on a blind agent multiplies blindness. Before the first loop it needs:

• Repo context: rules, README, how tests run, what “done” means
• A sharp done criterion. Not “do SEO,” but something like “meta 140-160 characters, FAQ with h3s, internal links in place”
• Permission to act: edit files, run tests, do not ask after every line
• Boundaries: no secrets in git, no force-push, no scope outside the brief

If you skip that, the loop orchestrates chaos. Vibe coding without constraints is just faster mess.

Step 2: Build the first fixed loop

A fixed loop is an endless shell cycle that sleeps, then prints a unique line. The agent watches for that line and runs the prompt.

while true; do
  sleep 300
  echo 'AGENT_LOOP_TICK_review {"prompt":"Check git status, open todos, and CI. Do the next clear step. Do not expand scope."}'
done

What matters:

• Unique sentinel: AGENT_LOOP_TICK_review must not appear anywhere else in logs
• Prompt in the payload: the tick wakes, the JSON prompt says what to do
• Run once immediately: do not wait five minutes for the first heartbeat
• One loop per job: do not reuse the same tick for SEO, tests, and blog posts

In practice I tell the agent something like: “Loop every 5 minutes: keep the open brief going until the checklist is green. Then stop and tell me you are done.”

Step 3: Move from polling to events

Five-minute polling is fine until you notice half the ticks are “nothing new.” Then you add a watcher:

# Fallback heartbeat if no event arrives
sleep 600
echo 'AGENT_LOOP_WAKE_ci {"prompt":"Check CI. If green, next step. If red, isolate the failure and fix it."}'

On top of that, a watcher that fires only when something relevant changes: a log goes green, a pipeline finishes, a file appears. The agent wakes because the work is there, not because the clock said so.

That is the shift from “keep poking the AI” to “wake the AI when there is work.” That is what building agent loops means in a grown-up workflow.

Step 4: Orchestrate several agents in parallel

One agent is a coworker. Several agents are a team, and teams need interfaces or they overwrite each other’s files.

My rough pattern:

• One owner agent in the main session: prioritizes, reviews, starts loops
• Subagents for isolated jobs: “find every internal link,” “explain why this test is red,” “inspect only this module”
• Never two writers on the same file. Parallelize by file, by language (DE/EN), or by layer (research vs. patch)
• Written handoffs: what is done, what is open, which command is next

Orchestration here is literal: who plays which instrument when. It is not “throw as many models as possible at the same diff.”

Step 5: Stop the loop again

A forgotten loop is expensive and stupid. It burns tokens, wakes the agent at night, and makes “just one more” edits to an article that was already done.

Stop rules I give agents:

• Stop when the checklist is met
• Stop when you could not do anything useful three times in a row
• Stop when the human says stop. Kill the PID and do not arm another heartbeat
• Then say, briefly: loop dead, why, what the last useful state was

Step 6: Make the loop a habit, not a ritual

At first every loop felt like an experiment. Now it is default: give the brief, arm the loop, do not close the lid, hotspot on, walk away. Come back, read the diff, tighten or merge.

That is the core of not writing code as a developer, and orchestrating agents instead. The loop is the layer between you and the keyboard.

The orchestra: subagents, rules, skills, and hooks

Loops keep the agent awake. The orchestra makes sure it does not start from zero every time it wakes. Without that orchestra, vibe coding is a talented intern with amnesia.

Rules: the agent’s operating system

Rules are durable instructions. They do not live in the chat. They live in files every session reads. Mine include: do not commit unless I ask, no secrets, meta descriptions between 140 and 160 characters, add internal links, do not inflate scope.

The better the rules, the less I repeat the same sermon in the prompt. That is the lever most people skip. They buy a better model. I sharpen the rules.

Skills: repeatable playbooks

A skill is a guide for a recurring job: publish an article, SEO audit, split a PR, set a loop. The agent reads the skill and executes, instead of guessing “how we do this here” every time.

When I explain the same flow a third time, it becomes a skill. That is optimization in the real sense: the agent does not get smarter, the system gets tighter.

Subagents: isolation instead of context mush

The main session is expensive. It carries the whole day. A subagent gets a narrow brief, finishes, returns with a report. Research, file search, “why is this test red”: that does not all belong in the same context-window stew.

Without subagents you are not orchestrating. You are overloading a chat until it hallucinates a file it read three hours ago.

Hooks: automation at the edges

Hooks run before or after tool calls: gate a shell command, format after an edit, kick the next step after a subagent stops. That is the layer where “agent, remember this” becomes a system that remembers for itself.

Rules, skills, subagents, hooks, and loops together are what I call my AI coding workflow. The chat is only the surface. Underneath it is a small operating system for work.

If you want a persistent personal AI rather than IDE sessions only, I also run OpenClaw as a personal AI assistant, with memory, tools, and recurring processes, not just a coding tab.

A workday with no hand-written code

Not an idealized deep-work calendar. A real day where agents own the keyboard.

Morning: Open the laptop, check the hotspot if I am not at home, scan open sessions. What did the overnight loop (or last night’s loop) leave behind? Read diffs, do not write them. One agent drafted an article, one went green on tests, one is stuck and needs a decision, not more autonomy.

Late morning: Write two or three sharp briefs. Not “make the page better.” Something like: “Unify internal links to this URL, anchor text = target keyword, keep it idempotent, then verify live.” Loop every 5 minutes. A second agent on another repo in parallel. I go into the garden. The laptop stays open.

Midday: Car, appointment, hotspot. The machine on the back seat or in the backpack. I do not stare at it. I check when a loop cycle should reasonably be done. If the session is dead, the hotspot dropped. That is the new “build failed,” only dumber.

Afternoon: Review. This is the remaining manual work: is this the solution I wanted? Did the agent blow the scope? Are DE and EN actually translated or just mirrored? Does the live page work? Then the next brief, the next loop.

The walk: Yes, really. Not for Instagram. Twenty-five minutes of walking is about how long an agent needs to run a checklist, if the thing has network. I come back, read the result, tighten or get ready to merge.

The day has little classic flow state. No disappearing into a function for four hours. Instead: many short conducting moments and long stretches where machines work while I am a human, or at least not glued to the keyboard.

This job needs different virtues than typing speed: clarity, patience until the loop ticks, the discipline not to poke the diff yourself, and a system that records what “good” means when you no longer see every line. I still use systematic debug-thinking for that, not for code I do not write, but for the briefs I do write.

Quality control when you do not type the code

The usual objection: “If you never type, you will not notice when it is wrong.” True, if review means “skim and hope.”

My counter is not blind trust. It is a different inspection layer:

• Diff first. Not the chat. The diff. What actually changed?
• Tests the agent runs, not decoration. Red is a brief, not an excuse.
• Check live where a live page exists. HTML in the repo is not the truth in the browser.
• Idempotence. Scripts and content patches must be safe to run twice.
• Small PRs. An agent touching 40 files has lost the plot. Split. Do not shrug.
• Definition of done in the prompt. If it is missing, the agent invents one it likes.

I do not have less responsibility. I have less keyboard and more judgment. Judgment is the job that remains when vibe coding eats the rest.

Sometimes the result is better than what I would have written, because the agent read neighboring modules I would have ignored out of habit. Sometimes it is confidently wrong. That is why review is not optional. It becomes the core skill.

Keep optimizing the system, not the one-off prompt

A single brilliant prompt is a trick. A system that turns average prompts into good work is the job.

What I keep tightening:

1. Cut briefs smaller. “SEO the whole cluster” loses to “one page, one keyword, one script.”
2. Checklists over mood. Agents can execute lists. They cannot execute vibes, which is a bit ironic given the name.
3. Turn feedback into rules. Any mistake I correct three times belongs in a rule.
4. Parallelize where files do not collide. Serialize where they do.
5. Shorten loops or make them event-based once I know the pattern.
6. Measure what shipped: live article, green tests, indexed page. Not tokens burned.

That is optimizing agent orchestration as a craft. It feels like platform engineering for one person. You build the factory you used to stand in.

The meta-loop that holds it together: agent works, I see the failure, I do not only patch the output, I patch the instruction that allowed the failure. If you only patch output, you stay at stage 2. If you patch the instruction, you eventually stop writing lines yourself.

For content that needs to rank, the craft is still there: structure, keywords, internal links, FAQ. I learned that as a developer anyway. See technical blogging for developers. The difference: the agent writes the shell. I specify the SEO constraints. I orchestrate until the checklist is green.

What this lifestyle costs: money, battery, attention, burnout

Always-on agents are not a lifestyle hack with no invoice.

Money and tokens

An agent allowed to “just check” in a loop for five hours is an expensive guard dog. Fixed loops with no stop condition are the easiest way to burn money. Work event-based, stop when done, do not panic-launch three models at the same bug.

Battery, heat, mobile data

A laptop under load in a backpack gets hot. The hotspot drains the phone. On the road you become sysadmin of your own pocket infrastructure. That is real ops work job descriptions do not list yet: software developer, plus power-bank management.

Always on call for your own machine

The laptop in the car, the garden, the walk: that is productivity and a trap. You train yourself never to go offline because “the agent is still running.” Same pattern as a Slack ping, except you built the ping.

I think this is the dangerous part. Not the AI. The inability to let a session die. When the loop becomes identity, you are no longer the orchestrator. You are on-call for a machine that has no concept of quitting time.

If that sounds like chronic tension, sometimes it is. Then the same basics apply as with any overload. Related reading: the burnout guide and burnout first aid. Vibe coding does not replace rest. It only makes rest easier to skip, because “it keeps going on its own.”

Quality drift and diffused responsibility

When nobody types the code, responsibility feels softer. It is actually harder: you sent the agent. The diff ships under your name. “The agent did it that way” is not a production excuse.

How to start without turning your life upside down

You do not need a laptop in the garden tomorrow. You need one brief an agent can finish while you get coffee.

1. Pick a task with a clear done. Write a test, unify a link, fix a bug with a repro. Not “rethink the architecture.”
2. Write constraints. What must it not do? Which files? Which test must be green?
3. Let it work alone. Do not narrate every file live. That is chat coding, not an agent.
4. Set a short loop (5 minutes) with a stop condition.
5. Review the diff, not the chatter.
6. Put the mistake in a rule or skill, not only in the next prompt.
7. Only then: let it run longer, hotspot, second agent, garden. Infrastructure follows the habit, not the other way around.

If you already think in two-week cycles, this maps cleanly onto a sprint rhythm. I use the same cut for life in Agile Life Sprints: small brief, review, retro, change the system. Agent orchestration is the same, with models instead of todo lists.

Frequently asked questions

What is vibe coding in a developer’s daily work?

Vibe coding means you set the goal and constraints, and an AI coding agent writes and edits the code. Day to day that is less typing and more orchestration: loops, review, parallel agents, instead of building line by line yourself.

Can a developer really stop writing code by hand?

Yes, for production work. I have not typed in repos myself for months. You need tools, tests, rules, and a clear definition of done. Without review and stop rules you only produce faster junk.

What are agent loops and how do you build them?

An agent loop wakes the session on a timer or an event and runs the same brief again. In practice: a shell loop with sleep, a unique sentinel, and a prompt payload. Start with fixed intervals. Switch to watchers on CI or files once polling is waste.

Why carry a laptop and leave a phone hotspot on just to keep an agent running?

Because the session dies when the machine sleeps or the network drops. Loops, terminals, and watchers need runtime. A laptop in the car, the garden, or a backpack is not a quirk. It is infrastructure for always-on coding agents.

How do you orchestrate multiple AI agents without chaos?

One owner agent prioritizes, subagents get isolated jobs, never two writers on the same file. Write the handoff: done, open, next command. Cut parallelism at interfaces, not by launching as many models as you can.

Is vibe coding the same as copying code from ChatGPT?

No. Clipboard-from-chat is stage 2. Vibe coding in the strict sense is agentic: the agent reads the repo, edits files, runs tests, keeps loops alive. You steer the process. You do not paste snippets into the IDE.

How do you keep quality high if you never type the code?

Diff-first review, automated tests, live checks, small PRs, definition of done in the prompt. Responsibility stays with the human who launched the agent. “The model wanted it that way” does not count in production.

What is the biggest mistake when starting agent orchestration?

Oversized briefs with no stop condition, plus a loop that never ends. Second mistake: typing into the same diff while the agent works. Third: ignoring infrastructure (hotspot, battery) and wondering why the agent “just stops.”

Conclusion

AI development did not just make my day a bit more efficient. It replaced the job description. I no longer write code with my hands. I keep agents running, build loops, sharpen rules, dispatch subagents, review diffs. And for that I carry a laptop through the garden, the car, and the walk, phone hotspot on, as if that were the new compiler.

That is vibe coding as I actually do it. It works and it ships. It eats battery, tokens, and the fantasy that quitting time is when the IDE closes. The IDE never closes. The session is supposed to keep running.

If you take one thing: stop trying to write better lines. Build a system that writes better lines while you decide which lines are allowed to exist. Then you are not unemployed as a developer. You are busy as an orchestrator, and the laptop in the backpack is only the visible symptom.

Further resources

• Developer life with AI agents: what this way of working does to energy, depth and code quality
• OpenClaw: a personal AI, not just chat sessions
• Technical blogging for developers: structure agents need too
• Debug-thinking: cut problems into clear steps
• Agile Life Sprints: steer in cycles, not in constant fire
• Burnout first aid if always-on tips into overload