AI-Assisted Coding

LLMs are a tool on the workbench. A good one. Use them.

The rule that makes everything else work: you own the code you ship — not the LLM. If you don’t understand a line, you don’t merge it. That’s the whole philosophy.

Where we stand

LLM-assisted coding is encouraged, in prototypes and in production.
Velocity gains are real — boilerplate, tests, refactors, docs get done faster.
Velocity is not a license to be lazy. Read every line. Run the tests. Understand what you shipped.
AI-written code holds to the same review standards as hand-written code. Same testing requirements. Same security scrutiny. No exceptions.

We’re not anti-AI and we’re not rah-rah about it either. It’s a hammer. Learn when to swing it.

Tools we use

Pick what fits how you work. They all do roughly the same thing with different ergonomics:

Claude Code — Anthropic’s CLI. Strong at multi-file edits, planning, understanding larger codebases. Our default.
opencode — open-source CLI, provider-agnostic. Good when you want to swap models or self-host.
Codex CLI — OpenAI’s coding CLI. Useful when you want GPT’s style.
Gemini CLI — Google’s. Free tier is generous; decent for smaller tasks.
IDE integrations (Cursor, GitHub Copilot, JetBrains AI) — fine, same rules apply.

Don’t paste client or EGCA code into random consumer chat UIs. The CLIs above respect API data policies; consumer ChatGPT / Gemini chat apps don’t necessarily.

Where LLMs shine

These are the tasks where you should just use them:

Boilerplate — CRUD handlers, API route scaffolds, Zod/Pydantic schemas from a description.
Unit + integration tests — a well-prompted LLM writes a better first pass than most juniors first-try.
Refactors — “rename this across the repo”, “extract this into a hook”, “convert this callback to async/await”.
Explaining unfamiliar code — paste a 200-line file, ask “what does this do and why?”. Faster than reading cold.
SQL + regex — humans are bad at these. LLMs are good. Always verify against real data.
Docs — README drafts, docstrings, API docs from code.
Migrations / config skeletons — Drizzle migrations, GitHub Actions workflows, Dockerfiles, Terraform if you have it.
Debugging help — paste the error + relevant code, ask for likely causes.
Commit messages + PR descriptions — if you haven’t tried this, try it.

Where to be careful

Treat these like handling sharp objects — the LLM can help, but you triple-check:

Auth and authz — token handling, session management, access control. One wrong line = security incident. Pair-review mandatory.
Migrations that drop / alter columns — LLMs confidently generate destructive migrations. Read them twice. Dry-run on a dev DB.
Financial / billing math — rounding, currency, tax. Write the test first, let the LLM fill in; never trust the math blind.
Cryptography — if the LLM is generating crypto.createHash or hand-rolling anything cryptographic, stop. Use the standard library primitive or a vetted package; don’t invent.
SQL on production data — LLM-written SQL has trashed prod elsewhere. Always EXPLAIN first. Always wrap in a transaction. Always run in read-only mode before a write.
API contracts / breaking changes — the LLM doesn’t know who’s consuming you.
Race conditions / concurrency — LLMs write plausible-looking concurrency bugs with a straight face.
Prompts sent to third-party models from our own apps — don’t let an LLM write the prompt without human review. It’s code.

How to use them well

Start with a plan, not a prompt. “Build the invoices feature” is a bad prompt. “Here’s the schema, here’s the existing invoices list page — add a Server Action that creates an invoice, with Zod validation and an integration test” is a good prompt.
Feed it context. Paste the relevant file, the schema, the error. Don’t make it guess.
Work in small, verifiable steps. One function. One test. Run it. Then the next.
Read every diff before accepting. Yes, every line. If you skim, you’ll ship a bug you’d have caught.
Run the tests after every change. Both yours and existing ones.
Ask “why” when it does something surprising. If the LLM picked an unusual pattern, understand it. Often it’s wrong; occasionally it’s a better way.
Use Git aggressively. Commit before a big LLM-driven change. You’ll want the easy rollback.
Don’t let it pull in new dependencies silently. If the suggestion imports a package you’ve never heard of, remove it or replace it.

How not to use them (the list of don’ts)

Don’t accept code you can’t explain in a code review. If a reviewer asks “why this branch?” and your answer is “the LLM wrote it”, that’s a fail.
Don’t paste secrets into prompts. API keys, tokens, production URLs, customer data. Ever. Scrub before pasting.
Don’t skip self-review. Self-review is already mandatory — it’s doubly important when you didn’t write the code line-by-line.
Don’t merge green CI without reading the diff. Tests prove the code does something. Only you prove it does the right something.
Don’t use an LLM to hide from understanding the codebase. If you’ve been working on a project for a month and can’t describe the data flow without the LLM, you’ve been outsourcing your job.
Don’t turn one ambiguous ticket into a 3,000-line PR. Same size rules as human-written. Split, verify, ship.
Don’t fight with the LLM. If it’s producing garbage after 2–3 tries, the problem is your prompt, your context, or the task shape. Step back. Think. Sometimes you need to write the first version yourself.

PRs with significant AI-generated code

Disclose in the description. Nothing dramatic — a single line is plenty:

“Scaffold generated with Claude Code, reviewed and modified by hand. Tests written manually.”

This lets reviewers calibrate scrutiny. It’s not a confession — it’s context.

What doesn’t need disclosure: autocomplete suggestions accepted in the normal IDE flow, small edits, commit message help. That’s just using the tool.

Data & privacy

Never paste client code into consumer chat UIs (free ChatGPT, Gemini web, etc.) — those products may train on input.
Do use the CLI tools (Claude Code, Codex, etc.) — they run against the API, which has stricter data policies and (depending on plan) no training on inputs.
Never paste secrets. Easy to forget — .env contents, DB URLs with creds, signed URLs, Azure SAS tokens. Scrub or redact.
Client work has extra rules — check the client’s DPA / contract before sending their code or data to any third-party model. When in doubt, ask a lead.

Prototype vs production — same rules

LLM-assisted prototyping is fine and encouraged — it’s a great fit for rapid iteration.

But when a prototype gets promoted to production, the Harden for production checklist applies regardless of who (or what) wrote the code. LLMs don’t get a free pass on auth, input validation, rate limiting, or testing.

In short

Use the tools. They make you faster.
Verify everything. You’re still the engineer.
You own what you ship.
If you can’t debug it, you can’t ship it.

That’s the whole rulebook.