AI Coding Assistants.

A practical field guide to the 2026 assistant landscape: choosing tools, driving them well, verifying their output, and rolling them out across a team.

Major tools at a glance

Quick chooser

• GitHub-centric org, need governance: Copilot Business/Enterprise.
• Want the most AI-native editor experience: Cursor (or Windsurf).
• Terminal workflows, big delegated tasks, CI automation: Claude Code or Aider.
• JetBrains shop: JetBrains AI + Junie before adding anything else.
• Hard privacy constraints or air-gapped: Continue + local models, or private-endpoint deployments (Bedrock/Vertex/Azure).
• Budget-sensitive individuals: Gemini Code Assist free tier, or Aider/Continue with cheap API models.

Rule of thumb: autocomplete accelerates typing, chat accelerates thinking, edit mode accelerates targeted change, agent mode delegates whole tasks. Each step up trades control for leverage; raise your review bar to match.

Agent mode guardrails

• Demand a plan first (plan mode / "propose before executing"); approve it before edits.
• Run in a branch, worktree, or sandbox; keep git checkpoints for cheap rollback.
• Deny-by-default command permissions; allowlist build/test commands only.
• Tests are the oracle: an agent with a runnable test suite self-corrects; without one it free-runs.
• Treat test-file diffs as the highest-suspicion category (agents "fix" failures by weakening tests).
• Human approval for: package installs, schema changes, deploys, anything touching prod.

Anatomy of a strong code prompt

1. Goal with exact signature/interface: "Write parseCsvLine(line: string): string[] ..."
2. Environment pins: language, framework, versions ("Node 20, Express 5, Sequelize 6").
3. Constraints: "no new dependencies", "use the existing http wrapper", "modify only this function".
4. Concrete input/output example (highest-leverage disambiguator).
5. Edge cases to handle, and explicit non-goals ("do not add caching or retries").
6. Verification hook: "include unit tests for the edge cases above".

Prompt like you'd write a ticket for a contractor who has never seen your codebase.

Recipes for common tasks

Constraint patterns that keep edits tight

• Scope fence: "Modify only validateOrder in orders.ts; touch no other file, import, or test."
• Non-goals: "Do not add logging, caching, or extra error handling."
• Style anchor: "Match the structure of validateInvoice" (paste it).
• Dependency lockdown: "Use only libraries already imported."
• Ask-first: "If anything is ambiguous, ask instead of assuming."
• Plan gate: "List intended edits as a summary; wait for approval."

Quality of output tracks quality of context. Most "the AI is dumb" moments are missing-context moments.

Techniques, cheapest first

Rules file starter template

# Project rules
- Build: npm run build; Test: npm test; Lint: npm run lint (run before declaring done)
- Architecture: routes/ -> controllers/ -> services/ -> models/ (Sequelize)
- Use the existing httpClient wrapper; never raw fetch
- Errors: throw AppError subclasses; no silent catches
- No new dependencies without asking
- Landmine: config/features.js is require()-cached; restart to see changes

Keep it short and imperative; treat it like code (PR-reviewed, updated whenever the model repeats a mistake).

Context hygiene for large codebases

• Curate, don't dump: attach the interface, the schema, and one exemplar - not the directory.
• Slice tasks to one bounded context per session; state integration points explicitly.
• Restart sessions when full of stale exploration ("context rot"); a fresh session + good brief beats a long noisy one.
• Directory-scoped rules files for subsystem-specific conventions.

Treat every AI change like a PR from a confident junior you cannot fully trust.

• Read the entire diff, including "boring" parts; hunt unrelated drive-by edits.
• Verify unfamiliar APIs/methods against the language server or official docs (hallucinations hide in plausible names).
• Check any new package on the registry before installing: age, downloads, maintainers, repo link (slopsquatting defense).
• Reason through edge cases: empty, null, boundary, unicode, huge input, failure paths, concurrency.
• Run the tests; if tests were generated, read them for tautological asserts, over-mocking, spec-vs-implementation mirroring.
• Security pass on sensitive surfaces: query construction, input validation, authz (not just authn), secrets, file paths.
• Confirm conventions: matches lint config, reuses existing helpers instead of duplicating.
• Explainability bar: could you walk a colleague through every line? If not, don't merge.

Hallucination catchers

• Typed languages + language server = instant ground truth; red squiggles override the model.
• Compile/run immediately; fast feedback loops are the cheapest verification.
• For packages: lockfiles + CI so a fake name fails loudly; internal artifact proxy with allowlist in corporate settings; agents must not auto-install.
• For APIs: check version-specific docs; models mix APIs across library versions.

Secrets and data

• Never paste .env files, tokens, connection strings, customer PII into prompts; use <PLACEHOLDER> values.
• Prompts leave your machine: assume logging/retention unless your tier contractually says otherwise.
• Secret scanners (gitleaks etc.) in pre-commit and CI; leaked-into-prompt = rotate immediately.
• Enterprise tiers: demand no-training guarantees + zero-data-retention agreements in the contract.

Licensing / IP

Generated-code vulnerabilities

Recurrent patterns: string-built SQL, missing input validation, path traversal, weak crypto (MD5/SHA-1/ECB), hardcoded creds, missing object-level authz, permissive CORS. Research (e.g. the Stanford study) shows assisted developers can write less secure code with more confidence.

Layered mitigation:

1. Rules files mandating parameterized queries + approved auth/crypto libraries.
2. SAST + secret scanning + dependency review as blocking CI checks.
3. Human security review required on auth/payments/upload paths regardless of diff size.
4. Agents: sandboxed, no prod credentials, approval gates on installs and deploys.

Enterprise control plane (large orgs)

• SSO/SCIM on all tools; role-gated agent capabilities.
• Central LLM gateway: model allowlist, per-team keys/budgets, audit logs, secret/PII redaction.
• Private endpoints (Bedrock/Vertex/Azure) or local open-weight models for sensitive enclaves.
• Repo/path exclusion lists so designated code never reaches a model.
• Make the sanctioned path easier than shadow AI, or it will be routed around.

Rollout phases

1. Foundations (2-4 weeks): security/legal review of tools; acceptable-use policy; baseline metrics (DORA keys, PR cycle time, survey).
2. Pilot (4-6 weeks): 8-12 volunteers incl. skeptics across 2-3 teams; real training (prompting, context, verification, agent guardrails); champions run office hours; friction log.
3. Evaluate and codify: compare to baseline; write team guidelines (mode selection, review norms, rules-file templates); choose defaults, allow documented exceptions.
4. General rollout: per-team onboarding, seeded rules files, updated review checklist, premium-usage budgets.
5. Ongoing: quarterly tool re-evaluation, seat-utilization review, shared recipes/failures channel.

Bake-off checklist (evaluating a new tool)

• Tasks from your real backlog incl. your worst legacy module (greenfield demos flatter every tool).
• 2-4 weeks minimum; week-3 usage reveals sustained value vs novelty.
• Measure: task outcomes (review iterations, later defects), workflow-fit survey, hard gates (SSO, audit, retention terms, price at scale incl. overage).
• Pre-register decision criteria before the pilot starts.

Code review norms for the AI era

• Committer owns every line; "the agent wrote it" carries zero weight; must explain any line on demand.
• Polish is no longer a care signal; key review depth to blast radius and novelty instead.
• AI smells to watch: plausible-but-wrong API use, duplicated logic vs existing helpers, over-broad try/catch, tests mirroring the implementation, unnecessary abstraction, drive-by edits.
• Enforce small PRs mechanically; generation makes unreviewable 800-line diffs cheap.
• AI first-pass review for mechanical issues; humans keep design and correctness judgment.

Usage policy: minimum contents

Approved tools/tiers; data boundaries (what may enter prompts); secrets handling; licensing rules (filters on, indemnified tiers); agent autonomy limits; review/accountability norms; disclosure expectations; mandatory training; incident reporting.

Keeping skills sharp

• Understand-before-accept invariant on every merge.
• Decide the design before prompting; compare model output to your intent.
• Interrogate the assistant ("why this approach, what breaks under load") to convert generation into learning.
• Periodic assistant-free debugging/practice; juniors hand-write core logic early and use AI mainly for explanation.

Pair programming etiquette

• Agree at session start whether completions stay on; in interviews, always ask first.
• Don't silently accept multi-line suggestions mid-discussion; narrate and review aloud.
• Disable ghost text during design-heavy moments; "the AI suggested it" is not an argument.

Metrics that work vs metrics that lie

Method

• Baseline before rollout; phased adoption gives you rough control groups; never compare across stacks.
• Watch the DORA-report tension: throughput up with stability down (bigger batches, more rework) is a net negative - instrument both sides.
• Team-level over quarters, never individual-level over sprints; individual metrics get gamed and hide tool use.
• Pre-register success criteria so results can't be cherry-picked.
• Acceptance rate: fine for diagnosing configuration (indexing on/off, rules files), meaningless across teams/languages.

Cost model (2026 ballpark)

Budget reality: agentic workflows burn tokens at roughly 10x chat rates - plan for overage, not just seats. Seat cost is trivial vs salary; the true evaluation is governance fit and workflow fit. Track cost per team and per merged change, and reclaim unused seats.

Model choice within tools

• Fast/cheap models: high-iteration low-stakes work (small edits, boilerplate, commit messages) where latency beats depth.
• Frontier reasoning models: hard debugging, multi-file refactors, agent runs - one right plan beats five cheap wrong ones.
• Long-context models: genuinely large cross-file reasoning.
• Pick a default + an escalation model; escalate after two failed attempts instead of thrashing; re-evaluate quarterly.

In low-pattern zones, flip the role: you design, the assistant critiques - ask it to list failure modes or steelman alternatives, not to decide.