AI Coding Assistants at Work: Productivity, Security, Rules

AI coding assistants (GitHub Copilot, Claude Code, Cursor and the like) were "autocomplete" two years ago; today they are tools that refactor across files, write tests, run commands and open pull requests. In enterprise teams the question is no longer "should we use them": they are being used — with or without an official decision. The real question is what decides the difference between a team getting 20% faster and a team producing 20% more technical debt. The answer is the rules, not the tool.

This article covers where AI coding assistants really pay off, how to measure productivity, the data, secret and license risks, the code-review and repository-rules practice, safe use of agentic tools, the effect on the team and a step-by-step enterprise rollout plan.

Where they pay off, and where they don't

Type of work	Gain	Note
Repetitive code: DTOs, mappers, CRUD, configuration, migration templates	High	The safest and most measurable gain
Writing unit and integration tests	High	Coverage rises; a human still decides "what to test"
Understanding, explaining and documenting legacy code	High	Valuable for characterization in modernization projects
Framework/library version migrations (Spring Boot 2→3, JUnit 4→5)	Medium–high	Good at mechanical transformation; may miss behavioral changes
SQL, regex, bash, unfamiliar APIs	High	Verification required: it produces queries that look right and are wrong
Architectural decisions, boundary design, data models	Low	Doesn't know the context; proposes "plausible" designs with wrong assumptions
Security-critical code (authentication, encryption, authorization)	Low / risky	Reproduces the common mistakes in its training data
Domain business rules (pricing, regulation)	Low	The rule is yours; the assistant only codes it and can't know if it's right
Performance tuning, concurrency bugs	Low–medium	Suggestions without measurement; verification is human work

The rule: the assistant pays off on work whose correctness you can verify easily. On work that's hard to verify (architecture, security, business rules), the speed it produces is paid back in review.

How to measure productivity

"Lines generated" and "suggestion acceptance rate" are vendor metrics; they don't measure enterprise value. What to measure: change lead time (idea to production), PR time from open to merge, production defect rate and change failure rate (DORA), the test-coverage trend and the code-review load (is review time rising?). Pilot design: 6–8 weeks, two similar teams or the same team before and after, the same metrics. The typical result we see in the field: clear acceleration on repetitive work, a 10–25% improvement in total lead time, a rising review load — unless the review process gets investment, part of the gain evaporates there.

Security and compliance risks

Code leaving the organization: Enterprise plans only (data not used for training, zero/short retention, SSO, audit logs); personal accounts are banned on company repositories. Read the data-processing addendum in the contract.
Secret leakage: The password or API key in a configuration file pasted into a prompt; secret scanning in the repository (pre-commit + CI) and excluding paths such as .env and secrets/ from the assistant's context.
Personal data: Logs and tables containing real customer data don't go into prompts; use synthetic data under data-protection law.
License and IP: Suggestions that reproduce large chunks of public code verbatim carry license risk; keep the tools' "reference code filter" on and check provenance for suspicious blocks.
Generated vulnerabilities: Generated code goes through SAST/DAST and dependency scanning; privacy by design rules are written into the rules file.
Hallucinated dependencies: The assistant suggests a package name that doesn't exist; attackers register those names and publish malicious packages (slopsquatting). Dependencies are added only from verified sources, with lockfiles and an internal registry.
Prompt injection: Agentic tools read repository files, issues and web pages; "run this command" instructions hidden in them can be executed by the tool. Tool permissions stay narrow, external content is treated as untrusted.

Quality rules: generated ≠ verified

Review is non-negotiable: Code the assistant produced is reviewed like code the author wrote; there is no "the AI wrote it" excuse, responsibility lies with whoever opens the PR.
No acceptance without understanding: The developer must be able to explain the generated code; if they can't, it doesn't go into the PR.
Tests first or together: Ask the assistant for the test before the code; if the test is generated too, a human reads what it actually verifies.
Small diffs: An 800-line generated PR can't be reviewed; the task is split.
Automated gates: Lint, formatting, SAST, dependency scanning and a coverage threshold in CI; the rules file tells the assistant about these gates too.
Write the architecture rules into the repository: Assistants read the repository's rules file (AGENTS.md, CLAUDE.md, .github/copilot-instructions.md and the like). If the team's conventions live there, generated code follows them.

# AGENTS.md — order-service

## Architecture
- Hexagonal: the domain/ package must not depend on Spring or JPA. Port interfaces under domain/port, adapters under adapter/.
- Any new external-system call goes through an adapter; RestClient is never used directly in services.
- Database changes only through Flyway migrations (db/migration/V*__*.sql); never ddl-auto.

## Code rules
- Java 21, prefer records and sealed types; no Lombok.
- Money amounts as BigDecimal with a currency (Money value object); double is banned.
- A unit test for every public service method, a Testcontainers integration test for every adapter.
- No personal data in logs; only correlationId and tenantId in MDC.

## Security
- Input validation at the boundary (Bean Validation); SQL only parameterized.
- Ask before adding a new dependency; only versions from the internal registry.
- Do not read .env, secrets/, *.pem files.

## Way of working
- Write a short plan before changing anything and wait for approval; do not produce diffs larger than 300 lines.
- Never say "done" without running the tests; command: ./mvnw -q verify

Agentic use: assistants that run commands

Extra rules for tools that run commands in the terminal, change files and open PRs: every task runs on its own branch and preferably in an isolated environment (container/sandbox); the assistant has no access to production credentials, the production database or deployment tools; destructive commands (deletion, force push, running migrations) require approval; a human reads the plan first, then it's executed; the CI gates apply to the assistant's PR exactly as to anyone's. Having the assistant review the assistant's own PR is not a control; a second pair of human eyes is required.

The effect on the team

The senior developer's job shifts from writing code toward steering and verifying: the right task definition, the right constraints, the right review. For the junior developer the risk is getting faster without understanding the code; the remedy is using the assistant's "explain" mode as a learning tool and asking "why this way" in review conversations. Two new skills gain value in the team: writing good task definitions and verifying generated output quickly. Both improve with training; buying a tool license doesn't replace training.

Enterprise rollout: step by step

Step	What's done
1. Policy	Which tools, which plans, in which repositories; secret and personal-data rules; the responsibility principle (the code belongs to its author) — one page, everyone reads it
2. Tool selection	Enterprise plan, SSO, data-processing agreement, audit logs, IDE and language support; 2–3 candidates, a two-week trial
3. Pilot	One or two teams, 6–8 weeks, metrics defined in advance; weekly feedback
4. Rules file and CI gates	AGENTS.md per repository; secret scanning, SAST, dependency and license scanning mandatory in CI
5. Training	Writing task definitions, verification techniques, prompt-injection awareness; a half-day workshop plus an internal guide
6. Measurement and scale-out	The pilot metrics decide; if there's a gain, roll out team by team with the rules-file template

Common mistakes in the field

Banning it: Usage goes underground, continuing with personal accounts and no rules; the worst scenario.
Buying licenses and walking away: Without rules, training and measurement the outcome is random.
Mistaking acceptance rate for success: High acceptance can mean low review.
Lightening review: "The AI wrote it, let's wave it through" — the source of technical debt.
Delegating security-critical code: Authentication and encryption are written by humans or verified line by line.
Broad permissions for agentic tools: An assistant with production access is one prompt injection away from an incident.

Frequently asked questions

Which tool is the best?

The tools change fast and differ by team; IDE fit, language support, enterprise data terms and agentic capabilities are the comparison criteria. A two-week trial answers better than any comparison article. The policy and the rules file are tool-independent; they stay even when the tool changes.

Who owns the generated code?

Most enterprise plans leave the output to the customer; but license risk remains for blocks that match public code verbatim. The contract and filter settings should be reviewed together with the legal team; this article is not legal advice.

Should we give it to junior developers?

Yes, but with accompaniment: in the first months, the senior has the junior explain the generated code, and the "no acceptance without understanding" rule is enforced strictly. Used correctly it accelerates learning; used without rules it bypasses learning.

Conclusion

An AI coding assistant gives the team speed; how much of it you keep depends on the rules: an enterprise plan and data terms, the rules file in the repository, an unchanged review discipline, CI gates, narrowly permissioned agentic use and measurement with real metrics. The team that sets these up gets faster; the team that doesn't goes into debt at the same speed.

To set up AI-assisted development in your team with rules, CI gates and training, see our software design and architecture and enterprise application development services.