Vibe Coding and AI: Execution Is Not Expertise

When you commission professional work, you expect someone to understand what you need, make choices you can discuss and deliver a result you can trust. Making something easier to produce does not resolve any of those expectations.

Today, a convincing presentation can be produced very quickly. Its appearance suggests that the work is finished. Decisions about its usefulness, limits and consequences may still be unmade. The gap between producing something and knowing how to deliver it is where I see the problem.

An application can look well designed and organise work badly. A change can be applied without error and interrupt an important function. A campaign can attract attention while communicating a promise the company cannot fulfil. Quality includes suitability, identity and operation as well as security.

AI is an excellent tool for amplifying skills. The unwarranted leap comes when the ability to operate it is sold as knowledge of the subject. Access to execution does not, by itself, establish competence to decide what should be done, check the result and take responsibility for it.

We know this question: if the tool does it, why hire a professional?

The question did not start with language models. Tools have been reducing the difficulty of tasks that once required considerable equipment, learning or production time. That change deserves to be distinguished from the conclusion that the professional work has been resolved.

In 2009, Apple introduced the iPhone 3GS with video recording, trimming and sharing on the phone. Capture and part of the editing process fitted into one device. Making a video became easier; its message, necessary shots, sound and pacing still needed decisions.

In 2013, Canva launched a design tool with elements users could drag into a composition. The announcement itself included uses for professional designers. In 2016, Wix announced ADI, promising websites built from answers to simple questions. These are concrete examples of execution becoming more accessible.

Faced with those tools, it is tempting to conclude that hiring someone who knows the craft becomes unnecessary. That conclusion confuses access to the means of production with mastery of the work. A finished composition does not establish that it communicates the brand. A published page does not establish that the business was understood.

Wix itself launched Studio for agencies and freelancers in 2023. This shows that accessible production tools and professional work can coexist. To me, the practical consequence is to adapt the service, choose where an intervention makes sense and demonstrate the value of decisions the tool did not make.

AI should amplify a skill you can exercise

I use AI in development to explore solutions, accelerate implementation and support review. The gain matters when I can understand the proposal, compare it with requirements and check its consequences. If I can no longer assess the result, speed has ceased to be a sufficient measure of progress.

The same criterion applies to models such as OpenAI’s GPT family, Anthropic’s Claude and Google’s Gemini, and to development tools such as Cursor, which integrate models into project work. Tool selection matters. Someone still needs to decide what context to provide, what actions to permit and what criteria to use when accepting the answer.

An agent gives the model an environment in which it can act: read files, change code, execute commands or communicate with services. The ability to do more things increases the importance of understanding which actions make sense and under what authority.

The professional boundary I defend is clear: sell only a scope you can understand, justify and validate. You can involve specialists when part of the work exceeds that competence, making responsibilities explicit. The customer should not receive a promise of expertise based only on the expectation that the model’s next answer will be correct.

Learning still requires experiments, mistakes and review. Doing that in a test environment, with fictional data and appropriate guidance, develops capability. Presenting an experiment as a finished product transfers the risk of discovering what you cannot yet assess to the buyer.

In an app, judgment becomes verifiable rules

Consider a booking application used by two businesses. Each has its own customers, schedules and documents. The interface displays a clean calendar, allows a time to be selected and confirms the booking. The presentation appears complete.

The first decision is to understand what booking means in that operation. An appointment may depend on a room, an available professional and time to prepare for the next session. If the system ignores one of those conditions, it may accept a choice the business cannot fulfil without exposing data or displaying errors.

I would start by writing verifiable conditions. If a room can only host one session at a time, two overlapping bookings must not both be confirmed. When two requests arrive together, both may have seen the room as available. Checking availability and confirming without protecting that interval leaves an opportunity to accept both.

The control must exist alongside the data determining availability, preserving the rule during confirmation. This is a concurrency problem: actions arriving at the same time. OWASP recommends addressing these race conditions in sensitive operations. Disabling a button on one person’s screen does not protect the system from another request.

Access to each booking also needs checking. Authentication identifies the person; authorisation determines whether they may perform an operation on that record. In a shared application, that includes checking which business owns the record. Hiding B’s data in A’s interface does not prevent A from requesting it directly from the server.

In an authorised test environment with fictional data, I would require at least these cases:

1. A’s account can read and change its own booking.
2. The same account requests B’s booking and access is refused without disclosing information.
3. An attempted change leaves B’s data intact.
4. Two simultaneous attempts to book the same resource respect the defined capacity.
5. The same rules remain valid for exports, attachments and background tasks.

Payments add another situation. If the provider repeats a notification after a communication failure, the system must recognise the event already handled and avoid processing the order twice. This property is called idempotency. It requires an explicit decision about identifying and recording events; a visual payment confirmation does not demonstrate it.

The work begins with understanding the operation, proceeds through implementing the rule and ends with checking it. That is how I would explain the value of web application engineering, including when AI produced a substantial part of the code.

Managing an operation requires knowing what a change can interrupt

On a server, a command can finish without error and the service start again. That confirms part of the execution. It does not account for every function depending on that machine.

Consider a firewall change: changing the rules that allow or reject connections. An agent can generate rules to close ports. Without understanding the dependencies, it may also cut off the connection used by backups or the service sending alerts. The application still loading does not establish that those paths remain operational.

I would require a sequence that could be explained before execution: identify necessary connections, save the previous state, define a way to recover access and test affected services afterwards. If the change can interrupt the remote session, recovery cannot depend on that same session staying open.

The existence of a backup file does not establish that the application can be recovered either. CISA’s preparation guide recommends testing backups in a recovery scenario. The copy needs to be checked in a separate environment to establish whether it can restore the data and resume the required operation. A supplier selling server management must define who monitors those controls and acts when they fail.

The same logic applies to an agent that reads customer records and issues refunds. OWASP documents the risk of prompt injection: instructions introduced through a message or document can redirect model behaviour. The risk gains operational consequences when the model has tools capable of acting.

A refund operation needs to check the user, organisation, order, limit and authority outside the model. Asking it to be careful in the prompt does not implement those rules. My recommendation is to restrict permissions and require approval for actions whose impact warrants it. Our article on malicious indirect instructions in agents develops that problem.

Automating an operation transfers actions to a tool. Responsibility for defining its limits, observing its operation and knowing how to recover still requires someone competent.

Appearance and metrics can conceal an unsuitable delivery

Professional quality also suffers in work with no obvious technical vulnerability. A result may be secure, visually polished and inappropriate for the audience or company identity.

Imagine an installation business that only serves particular districts and needs to visit a property before quoting. A campaign may generate plenty of forms by promising an immediate price. If it attracts people outside the service area or creates the expectation of a quotation without a visit, it is optimising an action the operation cannot fulfil. The dashboard may show cheap enquiries while staff spend time undoing the advert’s promise.

I would start by defining a useful enquiry: an appropriate service, a location covered, enough information to proceed and an expectation the business can meet. Then I would check the transition from advert to page and from page to the person handling the request. Evaluation would follow enquiries through qualification rather than stop at the form count.

Generating titles and descriptions does not resolve a search strategy either. The audience’s questions need to be understood and content organised to answer them. We develop the choice of objectives in our article on SEO and paid advertising. The tool can assist execution once there is a working hypothesis that can be tested.

In visual communication, the question is what identity and promise the material needs to convey. A logo that looks convincing in isolation may be indistinguishable from competitors; a beautiful interface may emphasise the wrong action. Joana Vidal develops that distinction in her article on AI design, brand identity and professional judgment.

In product design, an image leaves use and production conditions unverified. In videography, a polished sequence still needs a message, pacing and a context for viewing. Each craft has decisions that remain unresolved by generating plausible material.

Even in an interface, presentation does not confirm usability. Can you complete the form with a keyboard? Do you understand why a field was rejected? W3C warns about the effects of incorrectly applied ARIA, because adding accessibility attributes without expected behaviours can worsen the experience. Someone needs to observe the journey rather than merely recognise elements on screen.

For projects subject to the GDPR, someone needs to identify who determines the processing of personal data and who processes it on their behalf. The EDPB explains those roles and responsibilities. A generated privacy notice does not resolve that analysis; our article on GDPR in practice develops the issue.

Being valued requires making judgment visible and adapting the offer

Professionals have to respond to change. If a tool reduces the effort of execution, repeating the previous offer and expecting the customer to pay for the same difficulty leaves an important part of the conversation unaddressed.

Some tasks become something customers can do themselves. For others, AI assistance may reduce production time. The professional response is to understand which problems you can solve better, whom they matter to and how to demonstrate that work. It may require changing specialisation, scope or type of customer.

A business organising bookings across teams has different requirements from someone only seeking to publish information. A company with several services and markets may need brand consistency and editorial criteria that another does not yet have to manage. Choosing a segment should start with real needs and the ability to address them. Inventing complexity to justify a price also fails that principle.

Value starts with presenting decisions more clearly. Show what information you sought, which alternatives you compared, what you excluded and why. Explain acceptance criteria and provide examples of relevant tests. When the tool saves time, use that advantage to improve the result or make the proposal more efficient; pretending the work was manual does not legitimise the service.

During one month, a friend who had recently opened a business received several website proposals, each including a version already built, before a conversation about his needs. That case illustrates the reversed order: produce something first, then find the business to buy it. Presenting a solution as ready without trying to establish its suitability is a service failure. The customer is left to discover omissions the professional should know how to identify.

The criterion extends beyond that example. Selling a scope you cannot explain or validate gives your own learning less importance than the work deserves and transfers the risk to someone else. Trust in the service requires recognising where your autonomy ends, requesting review and refusing a promise you cannot yet substantiate.

At Webxtek Studio, that is how I approach technical consulting: framing the decision before increasing the amount of software. To the buyer, competence needs to become observable. For the provider, it needs to exist before the sale.

Price must correspond to work that can be explained

A quotation should explain the need identified and the delivery commitment. The speed of generation does not, by itself, determine that commitment’s value. It also does not justify charging for validation or follow-up that did not happen.

Price is not justified by invoking experience in the abstract. It is justified by making the necessary work, the ability to perform it and the responsibility assumed clear. A beautiful result full of unchecked assumptions does not become a completed delivery because an invoice is issued.

My position is to require competence before selling the service and to make that competence more useful through AI. Tools change the effort of production and require the offer to be reconsidered. Professionals need to keep learning, choose problems they understand and demonstrate why their decisions deserve trust.