If You Don’t Know What You Want, Use Claude. If You Do, Use GPT

The difference between vibe coding and AI-assisted software engineering is less about the model and more about who is behind the wheel.

vibe coding VS ai-assisted engineering

“If you don’t know what you want, Claude. If you know what you want, GPT.”

When I saw this sentence on X, it made me pause. With a single line, it seemed to capture two very different types of people building products with AI today.

On one side, you have those who have a vision but don’t know how to translate it into a technical system. They expect AI to deliver not just code, but the product idea, user flows, tech stack choices, and sometimes even the definition of the problem itself. On the other side are developers who predefine their domain models, architectural boundaries, data flows, and acceptance criteria, treating the model primarily as an execution tool.

The claim that the first group prefers Claude while the second leans toward GPT and Codex is a frequent talking point on social media. I can see why that sounds logical. But let’s be honest upfront: there is no credible research proving that “Claude users are just vibe coders, while GPT users are professional developers” based on experience level.

In fact, the idea that Claude isn’t widely used among highly technical developers directly contradicts the data. The Anthropic Economic Index shows that coding is one of the fastest-growing use cases for Claude, and its “extended thinking” feature is predominantly utilized by software developers and computer science researchers. Meanwhile, the Stack Overflow 2025 Developer Survey reports that 82% of respondents have used GPT models for development work over the past year. Yet, neither source suggests that “juniors use Claude, while seniors use GPT”.

Still, the saying touches on a much deeper truth:

The results you get from AI are often determined by how clearly you think, long before you even choose a model.

What does “vibe coding” actually mean?

When Andrej Karpathy coined the term “vibe coding” in February 2025, he was describing an extreme way of working: completely surrendering to the flow, prompting in natural language, and eventually “forgetting that the code even exists”.

Since then, the term has broadened. Today, people sometimes use it to describe any type of coding done with AI. I think that’s a mistake. A developer using Claude or Codex while actively writing tests, reviewing diffs, and making architectural decisions isn’t “vibe coding”. That is AI-assisted software engineering.

Former Google director Addy Osmani draws a similar distinction between vibe coding and AI-assisted engineering. In vibe coding, speed and experimentation take center stage; code correctness and maintenance costs are often secondary. In AI-assisted engineering, however, the human remains strictly responsible for the architecture, security, scalability, and long-term maintainability of the codebase.

This is why I don’t define a “real developer” by a degree, a job title, or how many lines of code they write by hand. To me, a real developer is someone who takes ultimate responsibility for the systems they build.

When a product breaks, it’s easy to blame the model. But when data is lost in production, when customer data is leaked due to broken authorization, or when a payment flow double-charges a client, “the AI wrote it this way” is not a valid technical excuse.

Why Claude might feel more natural to vibe coders

Someone without a technical background usually can’t give a model highly specific instructions. They simply don’t know what technical decisions need to be made yet.

They usually start with a prompt like this:

“I want to build an appointment scheduling app for small businesses. It should look modern and make it easy for users to book slots.”

This simple prompt leaves dozens of critical questions unanswered:

• Are these businesses single-location or multi-branch?
• Does each employee need their own calendar?
• How will time zones be handled?
• How do we prevent double-bookings?
• What are the cancellation policies and payment flows?
• What are the user roles and permissions?
• Which channels will be used for reminders?
• How is user data protected?

A vibe coder won’t ask most of these questions because they don’t know they exist. In this scenario, a conversational model that suggests directions and expands on vague briefs feels incredibly impressive. The user watches UI pages render rapidly on their screen and feels like the product is moving fast.

It is a fair observation that some users find Claude more intuitive during this exploratory phase. However, what’s being measured here isn’t always code quality. Often, it’s just conversational flow, the model’s prompting style, and how quickly it helps the user overcome the fear of the blank page.

This is a genuine value add. Rapidly prototyping, visualizing an idea, and helping a non-technical founder get a v1 off the ground is a massive win. The trouble only starts when the chaotic workflow that worked for a prototype is carried directly into a production system.

Why GPT and Codex appeal to developers who think clearly

An experienced developer rarely asks a model to “just build me an app”. Instead, they break the problem down into small, testable, and observable pieces.

For example, they might write a prompt like this:

“Prevent duplicate bookings for the same employee and time slot in our PostgreSQL-backed reservation service. Review the current transaction boundaries. Recommend an exclusion constraint or an equivalent thread-safe approach. Provide the migration script, write an integration test that reproduces the race condition, and do not alter the existing API contract.”

Here, the developer isn’t expecting the model to act as a product manager or a system architect. The context, constraints, and definition of success are already established. The model’s job is purely to research, implement, test, and prove its solution.

The best practices published by OpenAI for Codex encourage exactly this disciplined approach: providing accurate context, using files like AGENTS.md for persistent project instructions, outlining clear plans for complex tasks, defining explicit build/test commands, and establishing verified workflows for repetitive jobs. This methodology doesn't just hand the model an intention; it gives it an operating system.

This is why GPT and Codex can feel more “reliable” to developers who know exactly what they want. But the model doesn’t generate that reliability in a vacuum. The output is reliable because the developer fed the model a measurable goal, rich context, and strict error boundaries.

You can apply this exact same discipline using Claude Code, just as you can engage in chaotic, unchecked vibe coding with GPT. We shouldn’t confuse brand names with engineering maturity.

Why experience still matters

AI has drastically lowered the cost of generating code. But it hasn’t lowered the cost of distinguishing correct code from code that merely looks correct.

A CHI 2025 study conducted by Microsoft Research and Carnegie Mellon involving 319 knowledge workers found that as trust in AI increases, critical thinking tends to decrease. Conversely, when individuals have high domain expertise, their efforts to verify, correct, and integrate AI outputs increase.

This finding explains a very common phenomenon in software development. A non-technical user might look at a functioning UI and declare success. An experienced engineer, however, is looking at the invisible questions:

• Is this operation idempotent?
• What happens if two requests hit at the exact same millisecond?
• Are authorization checks happening on the client or the server?
• Is this database migration roll-backable?
• What is the timeout and retry behavior?
• Are we accidentally leaking PII (personally identifiable information) in our logs?
• Will this design hold up under load when the database grows?

A model might occasionally catch some of these issues on its own, but it still takes a human to notice when they are missed entirely.

Stack Overflow’s 2025 survey also highlights that experienced developers are far more cautious about AI outputs. While 46% of respondents express skepticism regarding the accuracy of AI tools, only 33% say they trust them. The “do not trust at all” sentiment is notably higher among veteran developers. Furthermore, 66% of developers cite “seemingly correct but ultimately incorrect” solutions as their biggest frustration, and 45% report that debugging AI-generated code often takes more time than writing it from scratch.

This skepticism isn’t luddism; it is the natural byproduct of responsibility.

More experience doesn’t mean using AI less

There is an interesting paradox here: experienced developers may trust AI less, but they often use it more effectively and aggressively.

In a July 2025 study by Fastly surveying 791 professional developers in the US, 32% of engineers with over ten years of experience reported that more than half of the code they shipped to production was AI-generated. For junior developers, that figure was just 13%. Senior developers also noted spending more time reviewing and correcting AI-generated output. While these self-reported figures don’t prove that experience alone drives this gap, they point to a strong correlation between engineering maturity and how AI is leveraged.

This doesn’t mean seniors are blindly letting AI run wild. Rather, experience allows them to map out a safe zone for its use. A senior developer can quickly identify where a model will save time, where it is likely to hallucinate, and which outputs should be rejected outright.

The person who gets the most out of AI isn’t the one who offloads everything to it, it’s the one who knows exactly what can be offloaded and what cannot.

Confusing velocity with progress

AI spits out code on a screen incredibly fast, making us feel intensely productive. But the volume of code written is not the same as a solved problem.

In a 2025 randomized experiment by METR involving 16 experienced open-source developers tackling 246 real-world tasks, developers using the AI tools of that cohort actually completed tasks an average of 19% slower. Intiguingly, even after the trial, those same developers still subjectively believed the AI had speeded them up.

While we shouldn’t map this result directly onto today’s cutting-edge models — METR has noted that this specific study does not represent the capabilities of newer models and updated their 2026 methodology — the experiment serves as a crucial warning: a frictionless AI experience does not automatically equal measured productivity.

Google DORA’s 2025 analysis of 1,110 software engineers highlights a similar “verification tax”. AI significantly reduces the time it takes to draft initial code, but a chunk of those time gains is immediately swallowed by the subsequent auditing and validation process. DORA’s takeaway is clear: AI acts as an amplifier. It accelerates teams that already have robust testing, clean APIs, and solid platforms, but it helps chaotic teams generate technical debt at record speed.

The 2026 Sonar State of Code survey points to the exact same bottleneck. Out of 1,149 professional developers surveyed, 95% spend time reviewing, testing, or fixing AI outputs. Only 48% consistently review AI-generated code before committing it. Additionally, 61% struggle with “code that looks correct but is completely unreliable.” Though self-reported, these findings align closely with the verification costs identified by DORA and Stack Overflow.

As generating code becomes cheaper, verifying code becomes infinitely more valuable.

Engineering systems, not models, build reliable products

What makes a product production-ready isn’t your favorite LLM. Reliability comes from how you answer these ten questions:

1. Are the problem and its scope clearly defined?
2. Does the domain model accurately map to real business rules?
3. Are the architectural decisions documented with clear boundaries?
4. Are the acceptance criteria measurable and testable?
5. Do you have unit, integration, and end-to-end tests in place?
6. Are security guardrails automated?
7. Is the system observable through logs, metrics, and tracing?
8. Can a bad deployment be rolled back instantly?
9. Has a human actually read and understood the generated diff?
10. Does the team take long-term ownership of maintaining this code?

Without these, even the most powerful model will only generate highly convincing technical debt.

But with them, both Claude and GPT become incredibly potent engineering tools. In fact, the healthiest approach is rarely model dogmatism, but matching the tool to the task: a conversational model for brainstorming, a coding agent for implementation, a secondary model for code review, and automated tests alongside human judgment for the final sign-off.

A two-stage workflow

If I had to rewrite the opening quote, I’d frame it like this:

“If you don’t know what you want, use AI to explore. Once you know what you want, stop exploring, lock down your specifications, and start engineering.”

In the exploration stage, lean heavily on the model to:

• Redefine the problem
• Surge hidden questions
• Propose alternative architectural and product approaches
• Expose hidden assumptions
• List potential risks and unknowns

During this phase, ambiguity is actually useful , you want to explore different possibilities.

In the engineering stage, the workflow must shift completely:

• Document the chosen architecture and the reasoning behind it
• Define non-negotiable system boundaries
• Break the task down into small, isolated units
• Establish strict acceptance criteria for each unit
• Instruct the model to run and verify tests
• Thoroughly review the diff
• Validate edge cases and security models independently
• Never accept “completed” without proof

In this phase, we want consistency, not creativity.

Final thoughts: Your model is not a senior developer

“Vibe coders use Claude; real developers use GPT” makes for a highly clickable social media post. It’s polarizing, provocative, and somewhat relatable. But reality has far more nuance.

There are world-class engineers using Claude daily, just as there are users deploying unreviewed GPT-generated code directly to production. Model preference is not a proxy for experience.

Still, the core intuition behind the saying holds true. A non-technical user expects the AI to think, decide, and execute all at once. An experienced engineer models the problem, draws the architectural boundaries, gives the model a tightly constrained task, and verifies the output.

The difference isn’t how clever your prompt is. It’s knowing what “correct” actually looks like.

AI can write code, suggest architecture, generate tests, and spot bugs you missed. But the responsibility of ensuring a product solves the right problem, remains secure, and is maintainable years down the road still sits squarely with the human.

Your model is not a senior developer.

The senior is the person managing the system, and taking ownership of the results.