Rapid Vibe Coding on Full Fat Models

Here’s a little playbook formed from thinking I’ve been doing over the last year (for those who don’t know, I’ve been on sabbatical but it turns out this stuff was essentially my hobby when I wasn’t breaking bones, meditating, or otherwise trying to “find myself”). I used all of this in the 10DS Hackathon I attended recently (shameless self-promotion on LinkedIn). I may well write a longer post about this soon.

Full-Fat Tooling or Bust

We need proper CLI agenting coding tools, direct from the providers. OpenAI Codex CLI and Claude Code are in a different league to Cursor, Windsurf and the like. I’ve tried most of them and the difference to me is simple: AI providers sell tokens, code-assist companies like Cursor resell tokens. Their game is to compress context to make margin. I want the same depth of thinking available to the teams training these models, not a watered-down proxy that’s optimised around rate limits.

Related: we need full-fat thinking models. The difference between GPT-5-codex-high (and peers in that bracket) vs older / non-thinking models is night and day. These models are running “thinking tokens” between tool calls, which makes a huge difference—especially when you’re leaning on autonomous file edits or multi-step reasoning in a session.

Safe Sandboxes for Dangerous Speed

You need to embrace ephemeral, corporately sandboxed high-permission environments. By which I mean, I can turn on vibe mode in something like Claude Code or Codex CLI with full internet access, and be perfectly fine with the prospect of a model going haywire via prompt injection or something like that. The rule is just: don’t let rapid prototyping live in the same environment as any of our regular IT. Give the AI room to run, but fence it away from anything that actually matters in production.

Audio as a Spec Engine

Audio is our friend. Non-MSTeams transcription has gotten unbelievably good, and you can funnel a lot of specification / requirements / vibes from spoken word into sensible prompts via ElevenLabs → ChatGPT summary / translation to prompt → Claude Code / Codex CLI. If you’re going to maximise a 2–3 hour meeting, have an open discussion with one phone recording everything, round it off, transcribe with a SOTA speaker-detection service, then use that as our basis for delegated development. It’s astonishing how much context you capture when the room stops worrying about typing notes and just talks.

MCP Everywhere

MCP tools are amazing. If we’re using a graph database, for example, as soon as we’ve populated some data, giving our code assistant an API to query it to inform the build makes development much easier. If anyone wants the long read: Revising the IATI Traceability Problem. Want the more philosophical one? MCP and Enveloping for AI.

The punchline is that an MCP-friendly environment turns your repositories, databases and APIs into tool calls. You stop copy-pasting schema docs into prompts and start letting the model inspect them live.

Ship Real Architecture from the Start

We can build mini versions of scalable architecture from the get-go. If you know what you’re doing it doesn’t take longer to build a well-coupled front end and a well-documented backend, rather than using a traditionally “quicker” stack for the proof of concept. For the 10DS hackathon I mentioned above, I opted for a Vite front end and FastAPI backend. That choice didn’t slow me down at all, but it meant from the start the code could be ported to the right places (EC2 / Supabase or similar for the API, Vercel for the front end, for example).

Related to this, a favoured pattern of mine: use an OpenAPI (fka Swagger) specification to marry the front and back end. Two people can independently vibe code, both knowing that they’ll play nicely when you integrate. Just point them both at the API specification and tell them to build to it / mock tests / etc.

flowchart LR
    subgraph Frontend["Front End"]
      direction TB
      dev_fe["Frontend Dev"]
      mock_ui[("Mocked API Client")]
    end

    subgraph Backend["Back End"]
      direction TB
      dev_be["Backend Dev"]
      test_suite[("Contract Tests")]
    end

    spec[["OpenAPI Spec"]]
    deploy[("Deployable Services")]

    dev_fe -->|builds to spec| spec
    dev_be -->|implements spec| spec
    mock_ui -->|auto-generated types| dev_fe
    test_suite -->|validates endpoints| dev_be
    spec -->|codegen + docs| deploy

    style Frontend fill:#1e293b,stroke:#fff,stroke-width:1px,color:#fff
    style Backend fill:#1e293b,stroke:#fff,stroke-width:1px,color:#fff
    style spec fill:#2d8cff,stroke:#fff,stroke-width:2px,color:#fff
    style mock_ui fill:#38bdf8,stroke:#fff,stroke-width:2px,color:#fff
    style test_suite fill:#fbbf24,stroke:#fff,stroke-width:2px,color:#fff
    style deploy fill:#10b981,stroke:#fff,stroke-width:2px,color:#fff
    style dev_fe fill:#6366f1,stroke:#fff,stroke-width:2px,color:#fff
    style dev_be fill:#f59e42,stroke:#fff,stroke-width:2px,color:#fff

The pattern is more than vibes: it’s enforced contracts and auto-generated SDKs that keep the front and back in lock-step. Combine that with full-fat models and sandboxed environments and you’ve got the productivity stack for rapid build cycles.

TL;DR

1. Use the real models direct from the people who train them.
2. Give them a safe sandbox so you can crank the permissions and still sleep at night.
3. Treat audio as a primary capture format when the room is busy ideating.
4. Wire up MCP so the model can inspect your actual systems.
5. Architect properly from the start, using shared specs so teams can vibe independently without breaking each other.

That’s the recipe that let us ship a serious prototype in a matter of hours, and it’s the baseline I’m carrying into the next set of experiments.