Build a QBCore Job With AI Safely

A QBCore job is not one client file and one reward event. A maintainable job usually has configuration, interaction points, permissions, server-owned rewards, inventory integration, notifications and a clear install path. AI is most useful when you force the work into milestones and make every network boundary explicit.

1. Write the job contract first

Define the job name, grades, duty rules, locations, required items, rewards, cooldowns and framework dependencies before asking for code. This prevents the AI from inventing incompatible assumptions halfway through the resource.

Also decide whether the resource should depend on qb-target, ox_target, qb-inventory, ox_inventory or another stack. Put those choices in one config instead of scattering them through client logic.

2. Separate presentation from authority

Client code should handle markers, prompts, menus and visual feedback. Server code should verify the player job, grade, distance when relevant, inventory requirements, cooldowns and rewards.

Do not send a reward amount from the client and then pay it directly. The server should derive trusted values from configuration or server state.

3. Build the happy path as one milestone

Start with one interaction from beginning to end: clock in, perform one task, validate it on the server and return feedback. Only after that works should you add multiple locations, progression, vehicles or management features.

This keeps debugging local. If the first milestone fails, you have a small event chain to inspect instead of a 2,000-line resource.

4. Ask AI for a security review before polish

Have the assistant list every RegisterNetEvent, every client-provided argument and what the server verifies. Then test the event with unexpected values and repeated calls.

FiveM documentation recommends treating client-triggered events as hostile input. That principle matters even on a friendly roleplay server.

5. Finish with install and test notes

A complete AI-generated job should explain dependencies, ensure order, configuration, database changes if any and at least a short multiplayer test plan. If those pieces are missing, the code is not yet a distributable resource.

Generate or review a small milestone, run it in Roblox Studio or on your FiveM development server, bring back the exact error or behaviour, and improve the smallest relevant part. That is how AI speed turns into reliable progress.

Turn the job into a state diagram Before adding vehicles or menus, write the stages of the job in plain language. A courier might be off duty, waiting for an assignment, collecting cargo, delivering cargo, and returning to the depot. Define which transitions are allowed and which side of the application controls them. This prevents separate event handlers from making contradictory assumptions about whether a player has started or completed the same assignment.

Choose a stable identifier for each assignment and decide where its authoritative state lives. A player reconnecting should not receive another reward simply because the client no longer remembers the first completion. Likewise, a server restart should have an intentional recovery rule. You might cancel unfinished assignments with a clear notice or restore eligible progress from storage. Document the choice before asking AI to implement it.

Keep rewards and permissions together For each completion request, identify the job, grade, assignment, location, required items, and previous completion state that must be checked. Store reward rules on the server. The client can request an action and display feedback, but it should not choose its own payout or report a trusted final distance. Request one server function that performs the completion decision so later features do not accidentally create a second payment route.

Think about failure between item removal and reward delivery. If the operations use different systems, ask for an explicit recovery strategy and an audit record. Do not call a pair of unrelated functions “atomic” simply because they are beside each other in a script. Use a design appropriate to the database and inventory APIs you actually have, then test interruptions on a private server.

Test with two different players Run the normal job with one player, then repeat it while another player attempts to interact with the same objects. Check that assignments are not mixed and that one player cannot complete another person's delivery. Test leaving the area, changing jobs during an assignment, reconnecting, and restarting the resource. These cases expose errors that a solo demonstration will miss.

Record expected outcomes before the test. For example, a second completion request should produce no additional reward, an unauthorized grade should receive a clear denial, and a missing configuration item should produce a useful diagnostic. Give failures back to Stellar with the relevant code and reproduction steps. Request a focused patch and repeat the failing test before adding another feature.

Hand the resource to someone else Finish with a short installation guide, a configuration reference, and the acceptance checklist. Name every dependency and include the start order that your test actually used. Keep development data separate from the live server. A job is ready for a wider trial when someone else can install it, understand its rules, and recover from a failed assignment without asking you to explain hidden assumptions.

Related guides

Want it fixed for you? The £99 Priority Script Fix is a one-off fix for a FiveM or Roblox script. Memberships start at £8 a month on the plans page.