Orientation

Vibe coding describes a workflow where the primary mode of writing production software shifts from typing every expression manually to directing, reviewing, and refining code generated by AI assistants. Instead of implementing each function from scratch, a developer states an intent—often in natural language or a concise prompt—and the assistant returns a scaffold, a transformation, or a full function. The “vibe” is the developer’s mental model of what the code should do, while the assistant handles the mechanical details: syntax, boilerplate, routine library calls, and basic type‑level plumbing. This mode matters when the goal is speed of exploration, rapid prototyping, onboarding to unfamiliar codebases, or filling in well‑understood patterns without friction. It matters less when the code path is security‑critical, performance‑sensitive, or requires deep domain knowledge that an LLM cannot reliably infer. In those cases, the developer reverts to meticulous hand‑writing, but the vibe‑coding loop often provides a strong starting point that can be iterated upon.

Prototyping a service endpoint

When you need to see how an API behaves without writing the full handler, an AI assistant can generate a minimal skeleton in the language of your choice. For example, asking for a Flask route that accepts JSON and returns a validated payload might produce:

from flask import Flask, request, jsonify

app = Flask(__name__)

@app.route("/webhook", methods=["POST"])
def webhook():
    payload = request.get_json(force=True)
    # TODO: validate schema
    return jsonify({"received": payload}), 200

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8765)

To test it immediately, you can spin the server and fire a curl request:

flask run --port 8765 &
curl -s -X POST http://localhost:8765/webhook \
  -H "Content-Type: application/json" \
  -d '{"key": "value"}'

Expected output:

{"received": {"key": "value"}}

If the schema validation is added later, curl can replay the same payload to confirm the response shape changes as expected.

When the prototype stabilises, git captures the iteration:

git add app.py
git commit -m "prototyped /webhook endpoint with AI assistance"

Generating module boilerplate

New projects often start with a directory structure, configuration files, and import paths that are repetitive but rarely tweaked. An AI assistant can output a cookiecutter-style template or a bare-bones Dockerfile, Makefile, and README. Because the tooling is standard, the result can be piped directly into the filesystem:

curl -s https://example.com/scaffold-template | tar -xz -C .

The extracted files may include a pyproject.toml with [tool.poetry], a Dockerfile using python:3.12-slim, and a src/{project}/__init__.py that imports logging and os. If the generated Dockerfile references a base image that your CI runner does not support, a quick docker build -t demo-image . will surface the mismatch:

docker build -t demo-image .

The flag -t names the image for later docker push or kubectl references. You can then edit the Dockerfile manually or re‑prompt the assistant with the exact error text.

Once the scaffold is sound, git tracks the new files:

git status
# On branch main
# Untracked files:
#   (use "git add <file>..." to include in commit)
#
#       Dockerfile
#       pyproject.toml
#       src/myproject/__init__.py
git add .
git commit -m "add AI‑generated project scaffold"

Debugging AI‑generated code

When the assistant produces a function that fails at runtime, the error text is usually a genuine language‑level or library error, not a fabricated one. For a Python module that imports a non‑existent package, pip will emit:

ModuleNotFoundError: No module named 'pandas';

You can install the missing dependency and re‑run the module in a single shell sequence:

pip install pandas -q && python -c "import mymodule; print(mymodule.hello())"

If the code contains a logic bug—e.g., an off‑by‑one in a loop—the stack trace will point to the exact line. At that point, git diff reveals what the assistant generated versus what you intended:

git diff mymodule.py
--- a/mymodule.py
+++ b/mymodule.py
@@ -3,7 +3,7 @@
 def compute(total):
     for i in range(total):       # original: range(total - 1)
         total += i
     return total

Correcting the range and committing the fix closes the loop:

git commit -am "fix off‑by‑one in compute()"

When the assistant hallucinates a function name or mis‑spells an import, the error will surface as ImportError or NameError. In production environments, those crashes become part of the incident runbook: the team learns to treat AI‑generated snippets as “first drafts” until a review step catches mismatched signatures or deprecated API usage.

Integrating into CI/CD pipelines

AI‑generated code enters the same CI pipelines as hand‑written code. A typical GitHub Actions workflow might lint, test, and build the artifact:

name: CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt
      - name: Lint
        run: ruff check .
      - name: Test
        run: pytest -q
      - name: Docker build
        run: docker build -t myrepo/${{ github.ref_name }} .

If the AI introduces a Dockerfile that uses a removed flag—e.g., --no-cache in a docker build that your runner does not accept—the build step will emit:

docker: Error response from daemon: unknown flag: --no-cache

Correcting the Dockerfile and pushing the updated image is then a matter of amending the workflow or the file directly, committing, and letting the pipeline rerun.

Sharp edges

  • Hallucinated dependencies: An assistant may suggest import foo where foo is not a published package. pip install foo will either fetch a typosquatted package or fail with ConnectionError or HTTP 404. Always verify the package name and version before installing.
  • Implicit state and context loss: LLMs have a finite context window. If a generation spans more than a few hundred lines, the model may forget earlier constraints, resulting in inconsistent variable names, mismatched function signatures, or duplicate definitions. Breaking the task into smaller prompts and reviewing each output mitigates this.
  • Security oversights: Generated code often omits input validation, authentication checks, or proper error handling. A curl request to an endpoint that trusts user data without sanitisation can trigger injection vulnerabilities. Treat every AI‑produced handler as untrusted until a security review passes.
  • API version drift: If the assistant references an endpoint that was deprecated in a recent release, curl -v http://api.example.com/v1/resource may return 410 Gone or 404 Not Found. Pin the API version in your code or update the prompt to use the current schema.
  • Tooling mismatches: A Dockerfile generated for a macOS‑local dev environment may use COPY . /app with permissions that fail in a minimal alpine base image. docker build will surface chmod: changing permissions of …: no such file or directory or permission denied. Adjust the USER directive or RUN chmod commands accordingly.
  • Review fatigue: Because the entry barrier is low, teams may accumulate many half‑baked AI snippets in the repository. Without a clear “AI‑generated code” label in git commit messages or a pull‑request template that mandates a review step, production incidents caused by unvetted code become harder to trace.

Platforms in this space

  • OutSystems
  • Mendix
  • Retool

These platforms expose visual‑first or AI‑assisted workflows that map onto the patterns described above, but the underlying mechanics—HTTP request/response cycles, SQL query generation, Git version tracking, Docker image building, and CI pipeline integration—are consistent across environments. Mapping the concrete commands and failure modes from this page to your chosen platform is a matter of substituting the generic tool invocations with the product‑specific equivalents your team already uses.

This page was rewritten on 11 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.