What is vibe coding? First prototypes, tools and limits for marketers

Vibe coding is a software development approach in which we describe the app we want to AI in plain language, have it generate the code, run and test the result, then fix it step by step with new requests. In marketing work we first build a prototypePrototypeA quick first version built to see whether an idea works. and test the idea on it.

For a product page calculator, we first describe the inputs and the result, check the calculation, then refine the layout. A screen that opens is not enough to launch; we also examine what the code does, where data goes and whether the result is usable.

What is vibe coding?

Vibe coding is a way of working in which AI writes the code and we move forward by testing the running result and correcting it with new requests. The term was coined by AI researcher Andrej Karpathy, and Collins Dictionary named “vibe coding” its word of the year.

We define the job, the behaviour to test and the result we accept. “Build a calculator” is only a start; we also state which input should give which result and compare the screen with that. Requesting, running and judging are one piece of work.

For a marketing team, the first gain is an idea that can be tried, such as a landing page layout or a post-form thank-you page. When payments, user accounts or personal data come in, we bring in a developer and agree on scope and launch responsibility.

How does vibe coding work?

Vibe coding works in a request → code → run → fix loop. Each round asks for one small change, runs the code and compares the result with the request; untested changes never pass.

A sample first request: “Build an installment calculator for the product page. Divide the total by the number of installments and show the result.” Then “Show the result in dollars,” then “Use one column on mobile.” We set the calculation rule; the tool adds no interest, fees or promotion terms on its own.

Each logged request notes the expected behaviour. A fix request states the input, the expected result and the error seen; instead of “It didn’t work, fix it,” we describe where the problem appeared.

A good prompt states the goal and the expected output; we run what the large language model generates and check that it behaves as asked.

What is the difference between vibe coding, low-code and no-code?

In vibe coding we generate code through plain language; in low-code and no-code we build from ready-made visual components and drag-and-drop interfaces. Vibe coding gives us real, editable code; the difference lies in how the app is built and where changes are made.

Take a form draft: we first decide the fields. With components we assess the visual interface; with generated code we describe field behaviour and run it. Either way, we check the data sent and the move to the thank-you page.

We weigh the need, the editing style and who maintains the work after launch. Neither option settles personal data and security decisions; we take those with a specialist before building.

Which tools are used for vibe coding?

Vibe coding uses terminal coding agentsCoding agentAn AI software assistant that carries out a task by reading and editing files and running commands., AI-assisted code editors and browser-based app builders. We choose by where we work with the code and how we test the result.

Cursor is an AI-assisted code editor. Claude Code is Anthropic’s terminal coding agent, as is OpenAI’s Codex CLI. Browser-based app builders need no installation and show a live preview where we type the request.

At markention we prepare this blog’s images and publishing scripts with Claude Code and Codex: images are drawn in HTML, converted to PNG with Chrome and checked by eye and on the site. Producing an image and seeing it render correctly are separate checks.

We write the job description before picking a tool. Reading generated files, running results and versioning changes are routine, whichever tool we use.

What do marketing teams use vibe coding for?

Marketing teams use vibe coding for landing page drafts, price or savings calculators, simple forms, thank-you pages, internal reporting tools and small content scripts. The first job covers a single need with a fixed scope.

The next step depends on the situation:

1. A one-page trial or an internal tool → We produce a prototype quickly with vibe coding and test whether it gives the expected result.
2. Personal data, payments or user accounts → After the first prototype we build the system with a developer and review security and data flow together.
3. A long-lived product or code many people will maintain → The developer sets the architecture; we use AI as an assistant within it.

We build the first calculator prototype in this order:

1. We define the job in one sentenceA product page calculator that shows the installment amount from the total and the number of installments.
2. We give a small first requestWe ask for the input fields and the result first, leaving layout tweaks for later.
3. We run and test itWe compare the result with the values we entered and also try leaving fields empty.
4. We pass the error on unchangedWe paste the error message as it is and state what we did before it and what we expected.
5. We keep versions with GitWe save a version at each step and note which request brought which change.
6. We have the code explainedWe have the calculation, data flow and changes explained and read it with the code.
7. We check before launchWe check the code, keys, form data, speed and accessibility, and launch only with human approval.

The job description also says when version one is done: a correct result and a usable mobile view. After each request we retest the calculation, including one field filled and the other empty; a result shown with missing input goes into the fix request.

In our vibe coding services we set the marketing need, the prototype’s limits, the launch checks and the point where a developer takes over.

What are the risks of vibe coding?

The main risks of vibe coding are launching unread code, leaving keys in the code, not knowing where form data goes and skipping speed, accessibility or version control. These checks start with the first prototype.

We never write an API key or password into the code; it stays on the server in an environment variableEnvironment variableA value kept outside the code, in the server’s runtime environment, for settings such as keys and passwords.. We have the code explain where the key comes from and check it with a developer. A key hidden on screen is not a security check.

We determine which fields the form collects and where submissions go. Flows with personal data are reviewed with a data protection specialist; in Turkey this falls under the personal data protection law, KVKK. A “Sent” message and data reaching the right place are tested separately; an unexplained data flow never goes live.

We also measure speed and accessibility: mobile input fields, readable results, a completable form. One desktop glance never closes the job; after a fix we rerun the action and save the working version.

What do we do when a prototype breaks?

When a prototype breaks, we read the error message, go back to the last working version and make the fix request smaller. We find the change that started the problem, pause new features and rerun the broken action.

This distinction decides the next move:

1. There is an error message → We paste it as it is, ask for a fix and repeat the same action to check.
2. Every fix breaks something else → We return to the last working version with Git and shrink the request.
3. We do not understand what the code does → We have it explained and do not move on unread; parts we cannot explain go to a developer.

If a layout change broke the calculation, we return to the working calculator, limit the next request to layout and retest. The request log stays with the versions.

Before launch, what the code does and where form data goes are settled. Requests, the working version and check notes stay together, so a teammate can repeat the same test. For turning a prototype into a mobile app, see What is Flutter; more on coding agents and prompts is in our AI articles.

Frequently asked questions