How To Vibe-Code a FiveM Script

Introduction to Welcome to the future of FiveM development

Welcome to the future of FiveM development. If you’ve been scripting for a while, you know the grind: boilerplate code, repetitive config setups, and hunting down syntax errors in the documentation. If you’re new, the learning curve of Lua and client-server networking can feel steep.

This guide is part of our complete FiveM content creation guide, covering everything from MLO design to scripting, vehicle modding, and building your creator brand.

Enter Vibe‑Coding.

It’s not just about letting AI write code for you; it’s about becoming a “technical director” while an AI assistant handles the manual labor. In this guide, we’ll walk through a repeatable workflow to build, harden, and polish a FiveM resource using AI as your copilot—without sacrificing quality or security.

For a broader look at AI tools in our ecosystem, check out our guide on Writing FiveM Scripts Using AI.

What is “Vibe‑Coding”?

In the context of this tutorial, vibe‑coding is the art of fast iteration with an AI assistant (like ChatGPT, Claude, or Cursor) where you follow a strict loop:

1. You define the Spec: You tell the AI exactly what needs to happen.
2. AI Drafts the Code: The AI generates the boilerplate, the logic, and the structure.
3. You Review & Validate: You check the diffs for security holes (trusting the client?), performance issues (busy loops?), and logic errors.
4. You Ship Decisions: You don’t write every line, but you make every architectural choice.

The Core Rule: The AI is the junior developer; you

The Core Rule: The AI is the junior developer; you are the senior lead. AI writes drafts; you ship decisions.

---

The Demo Script: “Item Use + Progress + Validation”

To learn this workflow, we aren’t just printing “Hello World.” We are building a real-world scenario that teaches the most important concept in FiveM: Server Authority.

The Script: vibe-consumable

• Action: Player uses an item (e.g., a “repair kit” or “energy drink”).
• Client: Checks if player is busy, plays an animation, shows a progress bar.
• Server: Verifies the player actually has the item, removes it, and grants a reward (health/armor/status).
• Security: We will specifically focus on preventing exploiters from triggering the reward without using the item.

If you need a refresher on the basics before diving in, read our Introduction to Lua Scripting.

---

Chapter 0: Setup & Tooling

Before we vibe, we need a studio.

1. Code Editor: VS Code is standard, but Cursor (a fork of VS Code with built-in AI) is the ultimate vibe-coding tool. It allows you to “Chat with codebase” and apply diffs instantly.
2. The Environment: A local FXServer for rapid testing.
3. The Mindset: “The Client is Untrusted.” This is your mantra. The AI will often forget this and trust the client blindly. You must catch it.

---

Chapter 1: Define the Spec

The biggest mistake developers make with AI is vague prompting. “Make a script that eats food” will give you garbage. “Make an ESX script where using bread triggers a 5s progress bar via ox_lib, then triggers a server event to remove bread and add hunger” will give you gold.

Our Spec for vibe-consumable :

Our Spec for vibe-consumable:

“Create a standalone resource compatible with QBCore/ESX (via bridge or config).

1. Config: Define items, duration, anim dict, and reward type (health/armor).

2. Client: Listens for a specific event or export to ‘use’ the item. Checks if ped is alive/not busy. Plays anim. Uses ox_lib for the progress bar.

3. Server: Listens for the completion event. MUST verify item count before removing. Adds reward.

4. Structure: config.lua, client/main.lua, server/main.lua, fxmanifest.lua.”

   ---

   Chapter 2: The Scaffold

   Let’s generate the skeleton. We want a clean folder structure immediately.

   “I need a folder structure for a FiveM resource named vibe-consumable. Please generate the fxmanifest.lua with standard metadata, a config.lua with one example item (water), and empty client/main.lua and server/main.lua files. Use ‘1.0.0’ version.”

Review:
Does the fxmanifest.lua include the client/server scripts correctly?

You can read here what a fxmanifest is	fx_version 'cerulean'
game 'gta5'	shared_script 'config.lua'
client_script 'client/main.lua'
server_script 'server/main.lua'
dependencies { 'ox_lib' }	Note: We added ox_lib to dependencies because we plan to use it.

---

Chapter 3: Implement the MVP Loop

Now, the logic. We’ll do this in two passes: Client, then Server.

Pass 1: Client Interaction
We’ll use ox_lib for the UI because it saves us writing NUI callbacks manually.

“Write the client/main.lua. It should have a function UseConsumable(itemName) that:

1. Looks up the item in Config.

2. Checks lib.progressBar using the Config duration.

3. If successful, TriggerServerEvent('vibe-consumable:server:consume', itemName).”

   Pass 2: Server Validation This is where vibe-coding

   Pass 2: Server Validation
   This is where vibe-coding shines. You can ask the AI to implement the logic, then ask it to “act as a security auditor.”

   “Write server/main.lua. Handle the vibe-consumable:server:consume event.
   IMPORTANT: Do not trust the client.

   1. Get the player from source (assume QBCore for this demo, or generic).

   2. Check if the player actually has the item in their inventory.

   3. If yes, remove item -> Heal Player -> Notify.

   4. If no, Log a warning that the player might be cheating.”

      ---

      Chapter 4: Hardening

      We have a working script, but it’s fragile. Let’s harden it.

      1. Server-Side Validation

        The AI might have just checked `if item` exists. We need to check `item.count > 0`.

“Refactor the server event. Ensure we check the specific quantity of the item. Add a cooldown table so a player can’t spam the event 10 times a second.”

2. Secure Events

The event vibe-consumable:server:consume can be triggered by any executor.

• Vibe-Check: Does the server strictly validate the input itemName against the Config? Yes. Does it check distance (if applicable)? Not here, but good to keep in mind.

        For more on optimizing your logic during this phase, read our guide on [Boosting Performance in FiveM](/blog/fivem-troubleshooting-guide).

---

Chapter 5: Performance & Reliability

We don’t want our script eating CPU ms.

Checklist for Review:

• loops: Are we running a Citizen.Wait(0) loop to check for key presses? Fix: Use RegisterCommand or KeyMapping instead.
• Exports: Are we using ox_lib correctly instead of heavy native drawing functions?
• Resmon: Check the resmon 1 in console. It should be 0.00ms when idle.

“Review the client code

“Review the client code. Replace any CreateThread loops for input detection with RegisterKeyMapping to optimize performance.”

---

Chapter 6: UX Polish

        A script works if it functions; it _vibes_ if it feels good.

1. Locales: Never hardcode text. Move all strings to locales/en.lua.
2. Notifications: Use a notification system (Configurable: ox_lib, qb-notify, okok, etc.).
3. Debug Mode: Add a Config.Debug toggle that prints helpful info to the console for server owners.

“Refactor config.lua to include a Locales table. Replace all hardcoded print/notify strings in client and server files with lookups from this table.”

---

Chapter 7: Packaging & Release

You aren’t done until you have a README.

“Write a README.md for this resource. Include:

1. Title: Vibe-Consumable
2. Dependency: ox_lib
3. Installation steps.
4. A snippet of the Config.
5. A disclaimer about the server-side validation.”

            If you are migrating this logic from an older framework, check out [Converting FiveM Scripts](/blog/how-to-migrate-esx-qbcore).

---

Workflows to Vibe-Code

There isn’t just one way to do this. Find your flow:

1. The Architect (Spec -> Generate -> Review -> Run):
   Best for new scripts. You write a text file with the requirements, feed it to the AI, and get a zip file’s worth of code back. You spend 80% of your time reviewing.
2. The Skeleton (Scaffold by hand -> AI fills modules):

                You create the files and functions: `function HandleEat() end`. You highlight that function and tell AI: “Fill this. Check for item ‘bread’, play anim ‘mp_player_int_eat’, duration 5000.” Best for control freaks.

3. The Archaeologist (Debug & Refactor Legacy):

                Paste an old, unoptimized script (maybe one with `while true do` loops) into the chat. Prompt: “Modernize this code. Use `ox_lib` for UI, remove busy loops, and fix the deprecated native calls.”

4. The Pair Programmer:
   Using tools like Cursor or Copilot, you type a comment -- Check if player has permission, and let the AI autocomplete the next 5 lines. This is the fastest “flow state” method.

---

Prompt Kit

Copy-paste these templates to speed up your workflow.

Copy-paste these templates to speed up your workflow.

The “Initial Brief” Template:

“Act as a Senior FiveM Developer. I need a [Framework: QB/ESX/Standalone] script that handles [Core Feature].
Constraints:

• Use [Library: ox_lib/qb-menu] for UI.

• optimize for 0.00ms idle.

• Separate Config from logic.

• [Specific Native/Event] must be used.”

  The “Security Audit” Template:

  “Analyze the following server-side code for exploits. Specifically, look for:

  1. Trusting client data without verification.

  2. SQL injection risks (if using SQL).

  3. Lack of rate limiting.
     Provide a refactored version that fixes these issues.”

     The “Native Finder” Template:

     “I need a FiveM native that handles [Action, e.g., attaching an object to a bone]. Please provide the native name, link to the FiveM Natives Reference, and a usage example in Lua.”

     tutYou can also check out the fivem docs here

     ---

     Quality Gates

     Before you push to GitHub or your server, pass these gates:

     • Security Gate: Did I verify the item count on the server before giving the reward?
     • Performance Gate: Is resmon 0.00ms-0.01ms?
     • Documentation Gate: Is the config.lua explained? Is the dependency list accurate?
     • Error Gate: Are there any script errors in the F8 console during the happy path (normal use) or edge cases (dropping item while using)?

     Assets Needed

     To follow this tutorial efficiently, ensure you have:

     • A test server (localhost is fine).
     • ox_lib installed and started.
     • A “testing” mindset—try to break your own script. Drop the item while the progress bar is running. What happens? (If you vibe-coded correctly, the server check will fail, and no reward will be given. Success!)

     Happy coding

     Happy coding! If you build something cool using this workflow, drop it in the FiveM forums.

     How to Use AI for FiveM