Vibe Coding x AI-Assisted Development: where experimentation ends and engineering begins

Vibe coding and AI-assisted development use the same tools. Cursor, Copilot, Claude Code, Codex, Replit, Lovable, it doesn't matter. What changes is not the product, but the behavior of the person at the keyboard. And this difference in behavior is what determines whether the code that comes out of it is used to validate an idea or to support a business.

What is vibe coding, in practice

Vibe coding is describing what you want in natural language and letting AI generate most of the code, often without in-depth review. Merriam-Webster defines the term as creating code, pages, or applications by asking an AI program what you want, letting the AI produce the result, without requiring the person to understand how or why it works.

Simon Willison, who coined much of the vocabulary we use for this today, made a distinction that I consider the most accurate I've ever read on the subject: using an LLM to write code is not, in itself, vibe coding. Vibe coding is building software with LLMs without reviewing what was written.

The flow usually goes like this:

1. The person describes an idea, for example "create a login system with a dashboard".
2. The AI generates an initial application.
3. The person runs it, sees the error, pastes the error back.
4. The AI corrects it, modifies files, adds new dependencies.
5. The person asks for more screens, more adjustments, more behavior.
6. In the end, something functional exists, even if no one fully understands the underlying structure.

I see no problem with this when the risk is low. For a disposable prototype, personal tool, proof of concept, quick hypothesis validation, this flow is great. It reduces initial friction and puts an idea on its feet in hours instead of weeks. The problem appears when this same flow becomes the way to build a product that goes into production with a paying customer on the other side.

Where the technical risk really lies

The risk of vibe coding is not the AI writing bad code. I write bad code sometimes, any senior engineer has written bad code. The risk is the absence of understanding, criteria, and technical responsibility for what was delivered.

When an application grows from successive prompts, without architectural design, without consistent testing, and without diff review, I've seen the same symptoms repeat in different projects: business rules scattered in the wrong place, overly coupled components, dependencies added without real need, lack of error handling, security failures in authentication and input validation, duplicated code, zero observability, non-existent acceptance criteria, and increasing difficulty in maintenance with each new change.

A study with 96 Google engineers measured a reduction in time for AI-assisted tasks, but made it clear that the gain depends on the context, task, and seniority of the person using the tool. An analysis of Copilot in real projects found gains in documentation, testing, and debugging, but clear limitations in complex tasks, large functions, and proprietary context, exactly the scenarios where critical software usually lives.

In other words: AI accelerates, but does not replace engineering. It never has.

What is AI-assisted development

AI-assisted development is an approach where the AI acts as a technical partner, but the responsibility for architecture, quality, security, and maintenance remains mine, the developer's.

In this model, I use AI to explore an existing codebase, suggest implementation, explain complex snippets, generate unit tests, review code, write documentation, propose refactoring, simulate error scenarios, generate migration scripts, support debugging, and automate repetitive tasks. The central difference is that I don't leave the process. I change positions: instead of writing each line manually, I act as architect, reviewer, and technical responsible for what is delivered.

GitHub's own documentation on Copilot Chat describes the tool as an interface for code doubts, concepts, test cases, and debugging, and GitHub also documents agents capable of searching a repository, proposing an implementation plan, changing code in a branch, improving test coverage, and opening a pull request for human review. The point I'm making here is precisely that: for human review. Not for automatic merge.

The difference that really matters: responsibility

In vibe coding, the question that guides the work is usually "did it work on the screen?". In AI-assisted development, the question I ask in any delivery is another: does it work, is it secure, is it testable, is it observable, is it sustainable, and can I explain this technical decision to another person?

Code generated by AI can pass the first visual test and still be far from ready for production. Production requires automated testing, security review, dependency analysis, logging, metrics, traceability, cost control, and maintenance criteria. GitHub's own documentation on responsible use of Copilot cites hallucination as a known risk of LLMs and reinforces the need for human review of any generated output. A Copilot Code Review evaluation found failure in detecting critical vulnerabilities, such as SQL injection, XSS, and insecure deserialization, which confirms something I've been defending for a long time: automated review by AI does not replace dedicated tools or human auditing.

Direct comparison

An example I've experienced firsthand: the login screen

Let's think about a common request: "create a login screen with password recovery".

In vibe coding, the prompt tends to be direct and vague:

"

"Create a beautiful login screen with email, password, login button, and recovery link. Use React and make it modern."

The AI generates the component, the person runs it, pastes the error back when something breaks, asks for visual adjustments, asks for button corrections. In the end, there's a screen that seems to work. What usually gets left out, because no one asked, is whether the password is transmitted over HTTPS, whether there's protection against brute force, whether the exposed error doesn't leak sensitive information, whether the recovery token expires, whether the flow allows user enumeration, whether there's rate limiting, whether the fields are accessible, whether there are tests, whether the logic is separated between UI, service, and domain, and whether the flow respects LGPD or internal privacy policy.

In AI-assisted development, the same request becomes:

"

"Implement the login flow in React following the existing architecture. Separate visual component, state hook, and authentication service. Don't store the token in localStorage. Handle generic error to avoid user enumeration. Create unit tests for form validation and integration tests for success, invalid credentials, and network failure. Before changing, explain which files will be modified."

The AI continues to help, but within a process that I define. I establish restrictions, ask for a plan before execution, review the diff, validate tests, verify security, and only then integrate into the main branch.

Where vibe coding makes sense

I defend vibe coding without reservation when the risk is low and the objective is to learn, explore, or quickly validate a hypothesis: disposable prototype, experimental landing page, personal automation, internal tool without sensitive data, interface simulation, proof of concept, learning a new library, initial boilerplate, UX experiment, quick hypothesis validation.

In these cases, speed is more valuable than robustness. The mistake is not using vibe coding here, the mistake is confusing "it worked in my environment" with "it's ready for a paying customer".

Where AI-assisted development is the only acceptable path

Financial system, authentication and authorization, integration with external API, sensitive data processing, SaaS product, system with SLA, corporate application, data pipeline, AI agent in production, multi-user system, any software that affects operation, revenue, or reputation. In these scenarios, I use AI all the time, but within an engineering process.

AI can generate the first version of a function, but it's up to me to evaluate complexity, readability, side effects, performance, and security. It can suggest tests, but someone needs to validate whether that test covers the right risk. It can review a pull request, but human approval remains final. This is not conservatism, it's the difference between delivering software and delivering risk disguised as software.

The new role of the developer

With AI in the flow, my value as an engineer has shifted from writing code quickly. It has moved to formulating problems, imposing restrictions, evaluating solutions, and sustaining systems in production. The skills I consider central today: writing technical prompts with sufficient context, breaking down large tasks into smaller steps, providing examples and counterexamples, reviewing generated code, identifying hallucinations, validating dependencies, demanding tests, measuring cost and latency, evaluating architectural impact, creating guardrails, documenting decisions, maintaining traceability.

AI does not eliminate engineering. It increases its importance.

I treat AI as an extremely fast junior, not as an invisible senior

The metaphor I use with my students is this: AI is a very fast junior developer, with good contextual memory, but without real responsibility for the business. It produces a lot in a short time, remembers APIs, patterns, and syntax, suggests reasonable solutions. But it also invents, omits risks, generates insecure code, ignores implicit requirements, and proposes solutions that seem elegant but don't hold up in practice.

That's why the right question is never "can AI do it?". The right question is: can I review, explain, test, operate, and maintain what AI did? If the answer is no, that code doesn't go into production, period.

Conclusion

Vibe coding and AI-assisted development are part of the same movement, programming mediated by natural language and generative models. But they don't represent the same level of technical maturity, and treating them as synonyms is what generates most of the incidents I see in projects that tried to skip steps.

Vibe coding is excellent for exploration, learning, and rapid prototyping. It democratizes access to software creation. AI-assisted development is software engineering using AI as an accelerator, where the responsibility for architecture, security, testing, maintenance, and observability remains mine.

The difference is not in using or not using AI. It's in how I use it. When AI generates code and no one understands, tests, or assumes responsibility for it, I'm just accelerating the creation of technical debt. When I use it within a technical process, with review, criteria, testing, and governance, it becomes one of the most powerful tools I've ever had as an engineer.

The future of development won't be choosing between human or AI. It will be knowing how to combine AI's speed with human technical judgment. That's the difference between coding on vibe and building real software with AI.