From Vibe Coding to AI Operations

Vibe coding is brilliant at reducing the distance between an idea and working software.

Describe what you need, inspect what comes back, make a correction and keep going.

Things that once needed a software team can now appear over a weekend with Claude Code and Codex at the helm.

The problem starts when the thing has to matter after the weekend.

Perhaps Codex needs to run a piece of work every morning. Perhaps Claude Code has to continue something another model began. Perhaps one of them can reach Jira, a database or an internal API. It can now change something outside the conversation, and it may be doing that when nobody is watching.

At that point, improving the prompt doesn’t answer the difficult questions. What is this capability allowed to do? Which information can it trust? Where does it record what happened? What happens when two models disagree? What still needs a human?

I don’t think of those as prompting questions anymore. They’re operating questions.

This is what I mean by AI operations in this essay. Not conventional AIOps, where machine learning is applied to IT operations, and not another agent framework. I mean the operating model around AI work: the authority, state, controls and handoffs that let different capabilities work inside the same environment without reconstructing the project every time a session starts.

I’ve been turning that approach into a cross-model engineering workspace scaffold. I can point it at a new workspace and establish the conditions under which Claude Code, Codex, deterministic tools and people will eventually work together.

The first run deliberately doesn’t build the product.

That last sentence is probably where the difference begins.

Most new AI builds begin with a task: build the application, connect the system, automate the process.

I now start one level above it.

Before the workspace decides what to build, it needs to know how decisions are made.

Which source is authoritative?

What can be changed without approval?

Where do requirements live?

Which actions are difficult to reverse?

What evidence counts as done?

The scaffold establishes an instruction hierarchy because an AI coding tool reads many kinds of language and they aren’t all instructions. A current user decision isn’t the same as an old note in a repository. A requirements document is evidence about the product; it doesn’t acquire authority to operate the machine merely because it contains a sentence written in the imperative. A previous model’s summary can be helpful without outranking the code and records now in front of us.

This sounds like a small distinction until an agent is allowed to read documents, use tools and alter external systems in the same run.

For cross-model work, I keep the common contract in one place. Claude Code gets a thin adapter that points back to it rather than a second, slowly diverging copy of the rules. The precise filenames are less important than the arrangement: shared rules stay shared, model-specific guidance stays thin, and neither model gets to invent a different constitution because its preferred instruction file has a different name.

Open an empty directory and ask an AI to create a system and it will start making decisions. A framework appears. Then a database, some tests, perhaps a cloud service. It is trying to be useful.

The difficulty is that each useful-looking choice converts an unknown into architecture.

My scaffold therefore has an explicit first gate where the workspace is created but the product is not. It records what is known, preserves the sources, establishes security hygiene and creates somewhere for requirements, decisions, plans, validation and handoffs to live. If no runtime has been selected, it says so. If the requirements haven’t been ingested, it doesn’t produce a fictional backlog. If no verified build command exists, it records that rather than borrowing one from a familiar stack.

This is more formal than vibe coding, although not as grand as it may sound.

The point isn’t to manufacture a miniature enterprise architecture department before anyone writes code. It is to stop the model filling every silence with a default.

The later gates follow the same logic.

Requirements are understood before architecture is approved.

Architecture is approved before implementation.

Release and operational readiness come after something exists to operate.

A model can recommend moving forward; it can’t record a human approval that never happened. Some projects will pass through those gates in an afternoon. They are still useful gates.

AI systems have context. That isn’t the same thing as organisational memory.

A good Claude Code session may contain a great deal of useful understanding: why an architecture was chosen, which constraint changed the plan, what failed in testing and what needs to happen next. Then the context ends. Codex arrives later, or the same model starts again without the reasoning it had yesterday.

If that knowledge existed only in the conversation, the project has forgotten it.

I put durable project intelligence in the workspace: original requirements and their interpretation, architectural decisions, current status, open questions, assumptions, validation evidence, runbooks and handoffs. Conversation can help create those records. It doesn’t replace them.

This changes scheduled automation in a useful way. Without durable state, the scheduled task needs an enormous prompt asking it to rediscover the project, infer what happened yesterday and make a sensible decision about today. With a maintained workspace, the prompt can be smaller. The capability wakes up, reads the current state, finds the approved boundaries and leaves evidence in a known place.

The intelligence has moved out of the prompt and into the environment.

That matters more now that the tooling really can wake up without us. Claude Code routines can run from schedules, API calls and repository events on managed infrastructure. OpenAI is also explicitly developing Codex around queued work and thread automations. The more often a capability begins without the conversation in which it was designed, the less sensible it is to make conversational memory carry the project.

There is a form of multi-agent work where somebody creates an AI product manager, an AI architect, a developer and a tester, gives them names and watches them talk to one another.

I understand the appeal. It looks like a team.

But, it doesn’t tell me who owns a decision.

In the scaffold, a team is a set of capabilities and accountability boundaries. Somebody needs to own requirements and acceptance. Somebody needs to consider architecture and security. Implementation and verification may need to be separated. Material decisions and production-impacting actions still need human authority.

One person or one model may cover several of those capabilities on a small build. On a riskier system, independent verification may justify a real separation. The team grows because the work has acquired a durable responsibility or a review boundary, not because a template had ten empty seats.

This also avoids a rather strange trap. An AI agent can be made to role-play disagreement between its own personas, but role-play isn’t independence. If the same model, context and incentives produced the requirement, the implementation and the approval, the labels above the messages haven’t created a control.

The useful questions are less theatrical.

Which capability is required?

Who or what can perform it?

Which decisions must not be made and approved by the same capability?

Sometimes the right answer is Claude. Sometimes it is Codex. Sometimes it is a deterministic script, and sometimes it is still a person who knows what the consequence feels like.

Models are useful where interpretation is genuinely required. They can work through ambiguous requirements, compare alternatives, find contradictions and assemble evidence from untidy material.

There are other things I don’t want a model to reconsider on every run.

A permission should be enforced. A schema should validate. An approval either exists or it doesn’t. A forbidden file path shouldn’t become acceptable because this morning’s reasoning was unusually persuasive.

The operating model separates those jobs. AI handles bounded judgement. Deterministic code, validation and platform permissions provide the guarantees. Higher-impact actions can still stop for human approval.

This becomes particularly important when a routine can update a project board, call a paid service or change data in another system. “Be careful” may be a perfectly good expression of intent. It is a poor permission boundary.

The result often uses less AI than the first design. That is not a disappointment. It means the model is being used where its variability earns its keep.

Claude Code and Codex don’t have to pretend to be one intelligence for me to use both of them. They need a reliable way to transfer work.

Sharing a repository is not enough. The receiving model still needs to know the objective, the scope, which files changed, what was validated, what wasn’t, whether any external system was touched and which decisions remain unresolved. If Git is involved, it needs the correct branch and a verifiable base rather than a story about where the work probably began.

My default is sequential handoff, especially when both tools would otherwise edit the same working tree. The outgoing capability records what it did and the evidence it has. The incoming capability checks the actual state, inspects the diff and reruns proportionate validation before recommending integration.

The second model isn’t there to trust the first model’s memory. It is there to inspect its work.

This is one reason I treat the engineering records as part of the deliverable rather than administrative exhaust. A successful run should leave the next capability with less rediscovery to do. If the project can only continue when the original chat is reopened and interpreted sympathetically, the handoff hasn’t happened.

Most of us discover this field in the opposite order. We see an MCP server, a Claude Code skill, a hook or a scheduled Codex workflow and immediately think of something we could make it do.

I now leave those mechanisms until the operating questions have answers.

Once authority, state, permissions, capability boundaries and handoffs exist, a repeated activity can be described properly.

What triggers it?

Which evidence may it read?

What is it allowed to change?

Where does its output go?

How does failure become visible?

When does it stop and ask?

Only then do I know whether the repeated work wants a model, a script, a connector or some combination of them.

The scaffold applies the same restraint to model-specific helpers. A Claude skill or Codex automation is added when it removes work that is genuinely repeated or enforces a boundary already approved. It doesn’t get to introduce its own security model or become the only place where the project remembers how an important operation works.

A routine is not the architecture. It operates inside the architecture.

I don’t want to turn the next step after vibe coding into an argument that everybody must now acquire a computer-science degree and spend ten years writing production software by hand.

There is another path through it.

You can learn enough about architecture, responsibility, state, permissions, evidence and automation to design a much more capable environment around these tools. Claude Code can perform one part of the work. Codex can perform another. Scheduled capabilities can repeat it. Deterministic controls can constrain it. Humans can keep authority over decisions with real consequences.

That is a different skill from writing every line yourself. It is also different from becoming exceptionally good at prompts.

The tools will move quickly. The model that looks indispensable now may be ordinary by next year. The operating questions are more durable: what is authoritative, what persists, what can act, what proves it worked and who is accountable when it didn’t.

Vibe coding gave more people a way to create software. I think AI operations is the point where some of those people begin creating the environment the software (and the AI building it) has to live inside.

Until next time,

Chris