How We Use AI Coding Assistants With Human Review

AI coding assistants have changed how software gets written, including at Jag Journey. They draft code, explain unfamiliar modules, write tests, summarize logs and suggest fixes. Used well, they let a small team maintain a large platform. Used carelessly, they can fill a codebase with confident mistakes.

We have settled on a simple stance: assistants are helpers that work inside our rules, and people remain accountable for what ships. Here is what that looks like day to day.

Written rules come first

An assistant only knows what it is told or what it reads. So we write things down. Our engineering standards describe the modules in our platform, the shared services every feature must use, how customer data stays separated, how payments must flow and how deployments happen. Each project carries instructions that assistants read before they start.

This is the same documentation a new human teammate would read. Writing it for assistants has made it better for people too, because vague guidance does not survive contact with a literal reader.

Some of the rules are short and absolute:

• Read the existing code before writing new code
• Never add a second payment path next to the shared one
• Scope every query, cache key and file to the right customer
• Deploy only through the pipeline
• Never put passwords, keys or session data in code, logs or chat

Specialist roles instead of one generalist

A general-purpose assistant tends to give general-purpose answers. For focused work we use specialist roles: a database specialist reviews schema changes, a security specialist reviews permission logic, a quality specialist plans browser checks, an accessibility specialist reviews keyboard and contrast issues. Each role carries its own checklist and its own boundaries.

The roles also have limits written into them. A specialist can recommend; it cannot authorize a payment, publish content to customers or change security settings on its own. Those decisions stay with people.

Human review is not optional

Every change an assistant produces is reviewed by a person before it reaches customers. Review is where we ask the questions an assistant may not: Does this duplicate something we already have? Does it respect the customer's settings? Does it fail safely when a service is down? Does it say anything to customers that is not true?

We also separate the kinds of evidence a change needs. Code that compiles is not the same as code that deployed, and code that deployed is not the same as a feature a real person used successfully. Our review notes record each one separately, so nobody mistakes "it builds" for "it works."

Where assistants help most

In our experience assistants shine at:

• Explaining an unfamiliar module before a change
• Drafting tests and edge cases a person might skip
• Converting repetitive patterns consistently across many files
• Writing first drafts of documentation and help articles
• Reading long logs and pointing at the likely cause

They need the most supervision when work touches money, permissions, customer data or anything public. That is where we slow down on purpose.

Honesty about what was checked

The most important habit we ask of assistants is the same one we ask of people: report results truthfully. If a test failed, say so and show it. If a step was skipped, say that it was skipped. If a check could not run because a service was unavailable, do not describe the feature as verified. Written instructions make this explicit, and review enforces it.

That honesty is what makes the rest of the system work. A summary that says "done" when it means "probably done" pushes risk onto customers. A summary that lists exactly what was proven, and what was not, lets the team decide calmly what still needs attention.

Assistants follow the same pipeline

Code from an assistant goes through the same review, the same commit history and the same deployment pipeline as code from a person. There is no side door. That keeps the history honest and makes every change traceable.

Why this matters to customers

Customers do not need to know which lines an assistant drafted. They need to know that every change was checked by someone responsible, against rules designed to protect their data and their money. That is the standard behind every product on our Technology & Impact page.

Frequently asked questions

Does Jag Journey let AI write code without review?

No. Assistants draft and suggest, but every change is reviewed by a person and released through the same pipeline as any other change.

Which tasks are AI assistants not allowed to do on their own?

They cannot authorize payments, publish content to customers, change security or credential settings, or take destructive actions without explicit approval from a person.

Do AI assistants make software less reliable?

They can if they are used without rules or review. With written standards, specialist checklists and human review, they help a small team cover more ground without lowering the bar.