AI coding assistants and company policy: what engineers should check

What company policies usually cover

Policies differ widely, but most address the same questions. Read yours with this list in hand:

If your company has no written policy, that doesn't mean anything goes. Ask your manager or security team and get the answer in writing.

Client projects add a second layer

As a forward deployed or consulting engineer, you often work in a client's environment. Their rules apply on top of your employer's:

• The client's contract may forbid sending their code to any third-party service.
• Their security team may approve a different tool from the one your employer uses.
• Work in some regulated sectors may prohibit external AI services entirely.

At kickoff, ask the client's engineering lead directly: "Are AI coding assistants permitted on this codebase, and if so, which ones and under whose account?" Record the answer. See what an FDE work week looks like for where such conversations fit.

A pre-use checklist

Run this once per codebase, not per session.

1. 1The tool is on the approved list for this repository.
2. 2I am signed in with the approved account (enterprise, not personal).
3. 3Required settings are enabled as the policy says.
4. 4The repository has no secrets in files the tool can read — or they are excluded.
5. 5The client (if any) has confirmed permission in writing.
6. 6I know how the team labels or discloses AI-assisted changes.

Reviewing generated code

Generated code needs review for the same failure modes as any code, plus a few that are more common with assistants:

A useful rule: you are the author of anything you commit, whoever typed it first.

A small example of the review mindset

An assistant might suggest this to fetch a user's orders:

def get_orders(conn, user_id):
    return conn.execute(f"SELECT * FROM orders WHERE user_id = {user_id}").fetchall()

It works in a demo. In review, it fails three checks: it builds SQL from input (injection risk), selects every column, and has no error handling. A reviewed version:

import sqlite3

def get_orders(conn: sqlite3.Connection, user_id: int) -> list[tuple]:
    if not isinstance(user_id, int) or user_id <= 0:
        raise ValueError("user_id must be a positive integer")
    cur = conn.execute(
        "SELECT order_id, status, total FROM orders WHERE user_id = ?", (user_id,)
    )
    return cur.fetchall()

conn = sqlite3.connect(":memory:")
conn.execute("CREATE TABLE orders (order_id TEXT, user_id INT, status TEXT, total REAL)")
conn.executemany("INSERT INTO orders VALUES (?,?,?,?)",
                 [("A1", 7, "shipped", 499.0), ("A2", 8, "processing", 120.0)])
print(get_orders(conn, 7))
assert get_orders(conn, 7) == [("A1", "shipped", 499.0)]

The assistant saved typing; the engineer supplied the judgement.

When you're unsure

If you can't tell whether a use is allowed, don't use the tool on that code until you've asked. Explaining a delay is far easier than explaining a breach. The same caution applies to personal projects that use company tools; see the side-project IP check.

For interviews

Employers increasingly ask how you use AI coding tools. A good answer names the tool, the policy you worked under, and a specific example of catching a problem in generated code — like the one above. The FDE for Freshers programme teaches production engineering habits — testing, code review and secure data access — alongside AI development, which is exactly what makes assistant use safe.