I have been “vibe coding” since 2023.
I just did not have a fashionable name for it at the time.
Since I started using ChatGPT in March 2023, AI has been involved in a significant amount of my development work. It has helped me understand unfamiliar concepts, plan application architecture, debug problems, write components, integrate APIs, improve existing code and turn ideas into functional products.
Some of those products were not experiments.
They were real websites used by real businesses.
The website I developed for Daniels Holiday Homes, for example, was built with considerable assistance from ChatGPT and OpenAI’s coding models. That website went on to generate substantial visibility, enquiries and direct business for the company.
It did not matter that AI had helped write parts of the code.
What mattered was that the website worked.
It ranked. It attracted traffic. It converted visitors. It solved a commercial problem.
That is why I find much of the current debate around vibe coding frustrating. It is often dominated by two extremes.
On one side are people presenting AI coding as if software development has become effortless and technical knowledge is no longer necessary. On the other are developers dismissing everything produced with AI as amateur work that will inevitably collapse under its own technical debt.
Both positions miss the point.
Vibe coding can produce terrible software.
It can also produce commercially valuable software.
The difference is not whether AI generated the code. The difference is who is directing it, how the work is structured, how the output is reviewed and—most importantly—which coding agent is being trusted to execute it.
Why I Tested Claude Code
At the beginning of 2026, the hype surrounding Claude Code was difficult to ignore.
Developers were praising its coding ability, its large context window, its command-line workflow and its apparent ability to work autonomously across substantial codebases. Some people spoke about it as though it had made every competing coding agent irrelevant overnight.
I wanted to test that claim properly.
I subscribed to a Claude Max plan and used Claude Code consistently for approximately three months. At the same time, I continued using Codex through a ChatGPT Pro plan.
This was not a comparison based on one prompt, one generated component or a synthetic coding challenge.
I used both systems for the kind of work I actually do:
- Understanding existing repositories
- Developing and modifying Next.js applications
- Working with APIs
- Debugging implementation problems
- Refactoring code
- Following detailed project requirements
- Maintaining consistency across longer tasks
- Continuing work after context compression
- Testing different model endpoints
- Evaluating token usage and operating cost
My conclusion was not particularly close.
For my development workflow, Codex was substantially better than Claude Code.
Not because Claude was incapable of producing good code. It occasionally produced excellent code.
The problem was consistency.
In production work, occasional brilliance is less valuable than dependable execution.
A Coding Benchmark Is Not a Development Workflow
A model can perform extremely well on a benchmark and still be frustrating to use inside a real repository.
Benchmarks usually evaluate whether a model can solve a defined problem. Real development is messier.
The agent must first understand what the actual problem is.
It must identify the relevant files, infer the existing architecture, preserve conventions, avoid altering unrelated functionality, follow explicit restrictions, test its implementation and recognise when it has misunderstood something.
That combination is where I noticed the clearest difference.
Claude Code could often generate a convincing solution. Codex was more likely to understand the solution I actually requested.
That distinction matters.
A technically impressive answer to the wrong problem is still wrong.
1. Codex Followed the Core Requirement More Reliably
My biggest problem with Claude Code was not syntax quality.
It was instruction fidelity.
I repeatedly gave Claude clearly defined requirements, boundaries and query parameters. Claude would acknowledge them, begin the task correctly and then make additional decisions that had not been requested.
It might change a related component, reinterpret a business rule, introduce an alternative structure or “improve” something that I had explicitly asked it to preserve.
Sometimes these decisions were reasonable in isolation. That was not the issue.
The issue was that they were not its decisions to make.
Software development is full of constraints that cannot be inferred purely from the code. A particular structure may exist because of a client requirement, an external integration, a deployment limitation, an SEO consideration or a future feature that is not yet visible in the repository.
When I tell an agent not to change something, I need it to respect that boundary.
Codex has consistently been better at retaining the central requirement throughout a task. It is more likely to distinguish between:
- What I asked it to change
- What it needs to inspect
- What it is allowed to refactor
- What must remain untouched
This makes Codex feel less like an overconfident junior developer improvising inside the codebase and more like an agent working under an actual technical brief.
2. Repository Understanding Was More Coherent
Working inside an existing repository is fundamentally different from generating code in an empty file.
The agent needs to build a mental model of the application.
It needs to understand how components interact, where data originates, which abstractions are deliberate, how state is managed, what conventions already exist and which files are actually relevant to the requested change.
During my tests, Codex was consistently better at constructing and preserving that mental model.
Claude Code often appeared to understand the repository at first. However, as the task expanded, its implementation could begin drifting away from the original architecture.
That drift created secondary work.
I would need to explain the requirement again, point out that an existing utility already handled the problem, restore a constraint Claude had overlooked or reverse an unnecessary change.
Codex required less of this supervision.
It was more likely to inspect the surrounding implementation before acting, connect related parts of the repository and produce a solution that felt native to the existing project rather than attached to it.
OpenAI describes Codex as an agent intended to complete end-to-end engineering work, including features, migrations and complex refactors. Its current workflow also supports project instructions and skills that allow teams to establish persistent standards for how work should be performed.
Marketing claims are not proof of performance. However, in this case, the intended product behaviour aligns closely with what I observed in actual use.
3. Codex Was More Autonomous Without Becoming Reckless
Autonomy is one of the most misunderstood concepts in AI coding.
A coding agent is not genuinely autonomous merely because it can edit many files without asking questions.
That is activity, not autonomy.
Useful autonomy means that the agent can:
- Understand the objective.
- Inspect the environment.
- Form a sensible plan.
- Execute that plan.
- Validate the result.
- Recognise failures.
- Correct them without abandoning the original requirement.
Claude Code could be highly active. It could read files, execute commands and make large numbers of changes rapidly.
But I found that its autonomy frequently came with unnecessary improvisation.
Codex was better at remaining inside the assignment.
It was more likely to complete the task end to end without either stopping prematurely or expanding the scope without permission. When it encountered a problem, its corrections were generally more closely connected to the original objective.
This produced a significant practical advantage: I spent less time managing the agent.
That is the metric that matters.
The purpose of an autonomous coding tool is not to produce the greatest visible volume of work. It is to reduce the amount of human intervention required to reach a correct result.
4. Claude’s Mistake Rate Became Operationally Expensive
Every coding model makes mistakes.
Codex makes mistakes.
ChatGPT makes mistakes.
Claude makes mistakes.
The relevant question is what kind of mistakes the system makes, how frequently they occur and how difficult they are to detect and repair.
The mistakes I experienced with Claude Code were often behavioural rather than merely technical.
It would:
- Disregard a stated constraint
- Modify something outside the requested scope
- Reintroduce an approach I had already rejected
- Assume a requirement instead of verifying it
- Claim completion while leaving part of the task unresolved
- Fix one problem while creating another elsewhere
- Drift from the original objective during longer sessions
These are expensive mistakes because the code can still look plausible.
An obvious syntax error is easy to identify. A subtly incorrect interpretation of a business requirement can survive testing and reach production.
I attempted to correct Claude’s behaviour through clearer instructions, rewritten project memory, reset sessions and revised skills. These changes sometimes improved the immediate session, but I repeatedly saw the same tendencies return.
With Codex, I experienced fewer instances where the agent understood the instruction, acknowledged it and then proceeded to disregard it.
That reliability is worth more to me than isolated moments where another model produces a more elegant function.
5. Context Compression Gave Codex a Major Advantage
Long-running development work eventually creates a context-management problem.
The conversation grows. Tool outputs accumulate. Files are inspected. Decisions are made. Failed approaches must be remembered. The agent eventually needs to compress or summarise what has happened so it can continue working.
OpenAI explains that Codex must actively manage its context because previous messages and tool calls become part of subsequent prompts, and long-running agent loops can otherwise exhaust the available context window.
Anthropic also uses compaction and external memory mechanisms for long-running agents. Anthropic itself acknowledges that compaction involves irreversible decisions about which information to retain, and that discarding the wrong context can cause failures in future turns.
My experience was that Codex handled this transition more effectively.
After compression, Codex was generally able to continue working on the central task while retaining the important constraints, previous decisions and intended outcome.
Claude Code was more likely to lose something important.
It might retain the broad topic while dropping a specific implementation rule. It might remember what feature we were building while forgetting why a previous approach had been rejected. In some cases, the session continued confidently but no longer reflected the complete project history.
This is more dangerous than the agent simply admitting that it lacks context.
Confident continuation after incomplete memory creates silent divergence.
Codex’s ability to compress, preserve the core assignment and continue with fewer hallucinated assumptions gave it a substantial advantage in longer tasks.
6. Token Efficiency Matters More Than Headline Pricing
API pricing comparisons are frequently oversimplified.
People compare the advertised input and output price of one model against another and declare a winner.
That does not tell you what a completed task costs.
The real cost depends on:
- The amount of repository context loaded
- System and tool instructions
- Prompt caching
- Cache creation and retrieval
- Reasoning or thinking tokens
- Repeated failed attempts
- Context compaction
- The number of tool calls
- The amount of corrective prompting required
- Whether the first implementation actually works
Anthropic’s own documentation notes that Claude Code costs scale with context size and that active agents can each maintain their own context window. Claude Code uses prompt caching and automatic compaction to reduce repeated token expenditure, but large contexts and multi-agent workflows still increase consumption.
During my API testing across multiple OpenAI and Anthropic models, I sometimes found only marginal differences in output quality. On narrowly defined requests, costs could also appear reasonably close.
The larger difference emerged at the workflow level.
Claude frequently consumed a substantial number of tokens when starting from a cold context. It then required more corrective interaction when it misunderstood a requirement or altered something outside the task.
Codex was generally more efficient during these cold starts and more economical across the full path from prompt to accepted implementation.
That does not prove that every OpenAI model is universally cheaper than every Claude model. Current model prices, context policies and subscription limits vary considerably across both platforms. OpenAI and Anthropic also price cached input, output and long-context use differently.
My claim is narrower and more useful:
In my projects, Codex produced a lower effective cost per successful task.
That is the number developers should care about.
A cheaper request is irrelevant when it takes four requests to repair the result.
Is Claude Code Bad?
No.
That would be an unserious conclusion.
Claude Code is capable. It can inspect repositories, write strong code and solve complicated problems. There were individual tasks where the quality difference between Claude and Codex was marginal.
There may also be developers whose repositories, prompting methods and workflows suit Claude better than mine.
But “Claude can produce good code” is not the same claim as “Claude is the better coding agent.”
After three months of sustained use, I found Codex better in the areas that most directly affect production work:
- Understanding the actual requirement
- Respecting scope and constraints
- Building a coherent model of the repository
- Completing tasks with less supervision
- Debugging without drifting away from the objective
- Preserving critical context during longer sessions
- Reducing corrective prompts
- Delivering better effective value for the money spent
Claude could impress me.
Codex was more likely to finish the job.
I will take the second quality every time.
So, Is Vibe Coding a Yay or Nay?
Yay—with conditions.
Vibe coding is valuable when it describes a faster interface between human intent and software implementation.
It is dangerous when it becomes an excuse to stop thinking.
I do not believe developers need to write every line manually for their work to be legitimate. We already rely on frameworks, libraries, documentation, Stack Overflow, reusable components, code generators and abstractions created by other people.
AI is another level of abstraction.
The critical question is whether the person using it can evaluate the result.
You should still understand:
- What the application is supposed to do
- How its major systems interact
- What data is being stored
- Where security risks may exist
- How to inspect a code diff
- How to test expected behaviour
- How deployment works
- How to recognise when the agent has misunderstood the business requirement
AI can reduce the amount of syntax you personally type.
It cannot remove your responsibility for the outcome.
My Current AI Coding Workflow
My workflow is not based on writing one vague sentence and accepting whatever appears.
I use ChatGPT and Codex across different layers of the development process.
1. I define the commercial outcome
Before discussing code, I establish what the product or feature needs to accomplish for the user or business.
Technical implementation comes after the objective.
2. I establish non-negotiable constraints
I specify which behaviour must remain intact, which files or systems should not be altered, what technologies are required and what would constitute an unacceptable implementation.
3. I make the agent inspect before editing
For meaningful changes, I want the repository understood before code is written.
The agent should identify the relevant architecture, dependencies and existing utilities rather than immediately generating a replacement.
4. I separate planning from implementation
I use ChatGPT to challenge the concept, identify edge cases and refine the technical approach. I then use Codex to operate more directly inside the repository.
5. I work in controlled increments
Large features are divided into verifiable stages. Each stage should have a visible output and a clear test before the next begins.
6. I review behaviour, not just code appearance
Clean-looking code can still implement the wrong requirement.
I test the actual user journey, business logic, edge cases and integration behaviour.
7. I treat the agent as capable, not authoritative
Codex can produce work beyond what I could write manually in the same period.
That does not make it automatically correct.
The final responsibility remains mine.
My Verdict
The argument over whether vibe coding is “real development” is already becoming irrelevant.
Businesses do not pay for the number of characters a developer manually types.
They pay for functioning systems, increased visibility, operational efficiency, customer acquisition and revenue.
The Daniels Holiday Homes website created real commercial value. AI assistance does not invalidate that result. It demonstrates what becomes possible when a person with product judgment, commercial understanding and technical literacy uses AI effectively.
The more important discussion is no longer whether developers should use AI.
It is which AI tools can be trusted with increasingly consequential work.
Based on my three-month comparison, my answer is Codex.
Claude Code is capable, heavily promoted and occasionally impressive. But in my experience, it was less disciplined, less reliable over long tasks, more prone to disregarding explicit instructions and more expensive at the level that actually matters: reaching an acceptable final implementation.
Codex understood the assignment more consistently.
It retained the assignment for longer.
And it finished more tasks without requiring me to repair the agent’s interpretation of what I had already explained.
For production vibe coding, that is not a marginal advantage.
It is the difference between AI accelerating the work and AI becoming additional work.