Vibe coding services: at AI speed, under engineer supervision.

We wrote this guide for marketing, product and small business teams who want to ship an internal tool, an integration, a landing page or a first product version (MVP) quickly with artificial intelligence (AI) coding agents. The mechanisms we describe are based on the coding agent documentation of Anthropic, OpenAI and GitHub, and, on the security side, on sources from OWASP, NIST and Google; the sources are listed by number at the bottom of the page. We verified product names and default settings against the source as of September 2026. Our own field observations are marked separately under the heading “Expert note”.

markention.com’s WordPress theme, admin panel and AI visibility analysis tool were also developed with AI coding agents, under engineer supervision. So below, as much as we explain where the speed comes from, we also explain where it needs to stop: scope, the loop between agent and engineer, security and testing, permissions, licensing and maintenance.

What is vibe coding, and where does the term come from?

Vibe coding is a way of developing software where you describe it in natural language and let AI write most of the code; Andrej Karpathy used the term in a post on X in February 2025.¹ Karpathy described it as a way of working where he forgets the code even exists, pastes error messages into the model without comment, and lets the code grow beyond his own understanding; by his own assessment, this approach wasn’t too bad for throwaway weekend projects.¹

The term spread quickly and today is used almost as the general name for fast software development with AI. In this service we take the speed part of the definition, but not the “forget the code exists” part: the agent writes the code, and an engineer reads it, tests it and puts it live. However capable models become, whether today’s AI or the superintelligence (ASI) people now debate, that responsibility stays with a person who can answer for the code that ships.

What does an AI coding agent do, and how is it different from a chat assistant?

A coding agent is an AI tool that reads your codebase, edits files, runs commands and tests, looks at the result and decides on its next step itself; what sets it apart from a chat assistant that only suggests text is that it can use tools. Anthropic writes that Claude Code works through three phases that blend together in a task: gathering context, taking action and verifying results.² An agent started in a project folder has access to the files in that folder, the commands you can run in the terminal and the git state; the user is part of the loop too and can stop the agent and change its direction at any time.²

The defaults of the three agents we use, or choose based on the client’s environment, are:

We took the surfaces and defaults in the table from Anthropic,²⁴ OpenAI⁵ and GitHub documentation;⁶ the sandbox in Codex is the isolation that limits where the agent can write and whether it can go online. What the three tools have in common is that the user grants the permissions. Anthropic says so plainly: Claude Code only has the permissions you grant it, and reviewing proposed code and commands for safety before approving them is the user’s responsibility.⁴

Which jobs is vibe coding right for, and which not?

Vibe coding fits jobs where the requirement is clear, the impact is limited and the result can be verified quickly; in code involving personal data, payments or critical business processes, the agent helps but engineering discipline carries the work. Agent makers write about this limit too. In the application card for its agents, GitHub states that generated code may look valid but not be semantically or syntactically correct, and may contain security vulnerabilities.⁷

The decision framework on this page works on the same logic: as criticality, personal or payment data and integration complexity increase, oversight grows.

Why do scope, prototype and acceptance criteria come before code?

Because the agent quickly does the job it’s described; if the description is wrong, it does the wrong job just as quickly. Anthropic writes that letting the agent jump straight into coding can produce code that solves the wrong problem, and recommends splitting the work into explore, plan, implement and commit phases.³ According to the same document, the most useful task description is self-contained: it names the relevant files and interfaces, states what’s out of scope, and ends with a verification step that proves the feature works end to end.³

Before coding starts, we clarify these five headings for every job:

1. Requirement: the goal, users, systems to touch and expected output are written on a single page.
2. Out of scope: what won’t be done in this version is listed explicitly; work the agent adds “to be helpful” is filtered out here.
3. Clickable prototype: screens are shown in a prototype first; production code doesn’t start until the flow is approved.
4. Acceptance criteria: each requirement is broken into testable sentences in the form “this input, this result”, and these are turned into automated tests.
5. Risk class: parts involving personal data, payments, permissions and writing to external systems are flagged.

How does the agent and engineer loop work?

In the loop, the agent writes the code and runs its own check; the engineer verifies that the check was set up correctly, that the result actually works and that the code is readable. Anthropic explains why plainly: the agent stops when the work looks done, and if it has no check it can run, “looks done” is the only signal it has; so it should be given a check that says pass or fail, such as a test suite, a build result or a screenshot to compare against.³ The same document recommends asking the agent for evidence, such as test output, rather than a claim of success.³

The mistake the document calls the “trust-then-verify gap” is exactly the risk of vibe coding: the agent produces an implementation that looks plausible but doesn’t handle edge cases. Anthropic’s advice is short: if you can’t verify it, don’t ship it.³ We also separate review from the session that wrote the code; a review session opened with a fresh context does a better review because it isn’t biased toward code it just wrote.³ Long sessions have another limit: as the context window fills, the model’s performance drops and the agent can start forgetting instructions given early on.³ That’s why we write lasting rules into the project’s instruction file; Claude Code can also read an AGENTS.md file if the repository has one written for other agents.²

What risks does AI-generated code carry?

There are four main risks: code that looks right but works wrong, security vulnerabilities, dependence on a library that doesn’t exist or isn’t safe, and trusting generated code too much. GitHub writes that code Copilot generates may contain security vulnerabilities or other problems, and should always be carefully reviewed and tested.⁷ The OWASP list for large language model applications also notes that a model may suggest insecure or non-existent code libraries, which can create vulnerabilities when added to software.¹⁰

The same OWASP document defines overreliance as users trusting model output too much without checking its accuracy; its recommendation is to set up human oversight and a verification process for critical work, and to train reviewers against overreliance.¹⁰ Where to look in web applications is shown by the OWASP Top 10:2025 list. The list starts with Broken Access Control; security misconfiguration, software supply chain failures, injection and Mishandling of Exceptional Conditions are also among the ten headings.⁹

What’s on the security and testing checklist?

Our checklist is based on NIST’s Secure Software Development Framework (SSDF, SP 800-218): code is read, running code is tested, external components are verified and access to code is restricted. SSDF groups its practices into four: prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities.¹¹ The framework defines code review, where a person looks at the code directly, and code analysis with tools separately; it also lists testing running code, verifying that third-party components meet requirements, and storing code under the principle of least privilege as separate practices.¹¹

• Secrets: API keys, passwords and tokens aren’t in the code, the repository or files sent to the browser.
• Access control: permissions are checked server-side at every endpoint; hiding a button in the interface doesn’t count as a permission check.
• Input validation: inputs are validated, queries are parameterized and outputs are escaped.
• Dependencies: added packages are checked for existence, maintenance, version and known vulnerabilities.
• Error handling: unexpected conditions are handled; error messages don’t show internal system details to users.
• Abuse limits: rate limiting and bot protection are put on public forms and API endpoints before launch.
• Tests: acceptance criteria, edge cases and previously fixed bugs are kept in automated tests.
• Logging: permission and external service errors are logged and tied to alerts.

How are the agent’s permissions and prompt injection managed?

We give the agent the narrowest permissions the job needs, and treat text coming from outside as data, not instructions. Prompt injection is a technique where an attacker tries to override or manipulate an AI assistant’s instructions by inserting malicious text.⁴ For this risk, Anthropic recommends reading proposed commands before approving them, not piping untrusted content directly to the agent, and using virtual machines when working with external services; it also adds that no system is completely immune to all attacks.⁴

OpenAI separates two settings for Codex: the sandbox mode determines what the agent can technically do, such as where it can write and whether it can go online; the approval policy determines when the agent must ask you before an action.⁵ The same document asks for care when turning on network access or web search, because prompt injection can lead the agent to fetch and follow untrusted instructions.⁵ GitHub likewise restricts Copilot cloud agent’s internet access, filters hidden characters in input, and prevents the person who asked for a pull request from approving it; by default, workflows in the repository also don’t run until someone with write access reviews and approves the code.⁶

How are licensing, ownership and maintenance handled?

On licensing, we look at whether generated code matches public code; on ownership, whose name the repository and accounts are in; and on maintenance, what’s monitored after launch. GitHub’s code referencing feature compares a Copilot suggestion, together with roughly 150 characters of surrounding code, against an index of all public repositories on GitHub.com; matches typically occur in less than one percent of suggestions, and the log shows the URLs of matching files and, where found, the name of the applicable license.⁸ GitHub also writes that the cloud agent can generate code identical or very similar to public code even when the “suggestions matching public code” policy is set to block.⁷

Before handover, we check the source of long blocks of code that look ready-made, and list the licenses of third-party code. The repository, hosting and service accounts are opened in your name; the legal status of AI output is a matter for your legal counsel.

For after launch, we use the four golden signals from Google’s SRE (site reliability engineering) book: latency, traffic, errors and saturation.¹² The book doesn’t define errors only as failed requests; it also counts requests that return a success code but carry the wrong content as errors.¹² In an integration, a request can look successful while an incomplete record lands in the CRM; that’s why we check the content too. On landing pages we also track speed with field data after launch; we cover that side on our website speed optimization page.

How do our vibe coding services work in the first 30 days?

The job of the first 30 days is to put the first audited version live and settle how maintenance will continue. For a small panel add-on, these steps take less time:

1. Week 1 · Scope: the requirement, out-of-scope items, acceptance criteria and risk class are written; screens are approved with a clickable prototype.
2. Week 2 · Development: code is written with the agent, on separate branches and with limited permissions; every change is tied to a test, and progress is shown to you as a working version.
3. Week 3 · Audit: engineer review, the security checklist, acceptance tests and the dependency check are completed.
4. Week 4 · Launch and handover: the release goes live on your infrastructure; monitoring alerts, release notes, setup documentation and agent instruction files are handed over.

Vibe coding service, software agency or doing it yourself: what’s the difference?

There are three common ways to build software with AI; what separates them is who looks over the code and who is responsible for it after launch.

How should you choose a vibe coding agency?

When you talk to a team that builds with AI, ask about oversight before speed:

1. Who reads the code: does an engineer read every change, or is the agent saying “done” treated as enough?
2. Automated tests: are acceptance criteria turned into tests, and are changes to test files read separately?
3. Agent permissions: which permissions does the agent run with, and does it have access to the live system or database?
4. Secrets: where are API keys and passwords kept, and are the repository and files sent to the browser scanned for them?
5. Repository and accounts: whose name are the code repository, hosting and service accounts opened in?
6. After launch: which signals are monitored, and how do you roll back to the previous release?

What determines the pricing of vibe coding services?

Because writing code has become faster, the cost isn’t set by lines of code but by scope, risk and oversight:

We work out the scope together in the first meeting, then send a written proposal. Hosting and third-party service fees are shown as separate items in the proposal and paid from your account.

Vibe coding services pricing: starting prices and ranges

The lower end of each range is the starting price; excluding VAT. Scope is confirmed in a written proposal after the first meeting. As of October 2026.

If you’d like to try a tool we built with this method, take a look at our free AI visibility analysis.

If you’d like to scope the job you have in mind together, pick a meeting day that suits you below; in the first meeting we settle together whether it will be a fast prototype or an audited release.