Developers spend much of their time reading code, writing boilerplate and looking things up. An AI assistant inside the editor suggests the next lines, answers questions about the codebase, proposes multi-file edits and writes tests, while the developer reviews every change. It is the most widely adopted AI use case in software engineering; the real questions in 2026 are governance (code and licence leakage, data residency) and honest measurement of productivity.
Problem & value
- Today: developers search documentation and forums, copy patterns from old code, write boilerplate by hand and wait for reviews. Onboarding into a large codebase takes weeks.
- AI value: faster routine coding, quicker onboarding via "ask the repo", less context switching, more consistent tests and docs.
- Evidence is mixed, not uniformly positive. A randomized trial by METR with 16 experienced open-source developers on 246 real tasks found that early-2025 tools made them about 19% slower, although they believed they were faster; METR itself labels this result as historical for early-2025 tools [1]. Controlled vendor-sponsored experiments report faster completion of a well-defined task [2], and the DORA research programme tracks AI adoption together with delivery stability [3]. Treat all numbers as context-dependent and measure in your own team.
Variants
- Autocomplete only (FIM): low-latency inline suggestions; small models suffice.
- Chat + codebase Q&A: side panel with retrieval over the repository.
- Agent mode in the IDE: the assistant edits several files, runs tests and terminal commands with approval (hand-over to fully autonomous agents: CODE-002).
- Public sector / regulated: air-gapped or sovereign deployment, no code leaving the network.
How it works
- editor event (typing / prompt / selection)
- context assembly (current file, cursor prefix+suffix, open tabs, imports, LSP symbols)
- retrieval (repo index: embeddings + keyword + code graph; rules files)
- code LLM (fill-in-the-middle for completion | chat / reasoning model for questions & edits)
- post-processing (syntax check, duplicate/licence filter, secret & PII filter)
- suggestion shown as ghost text or diff
- developer accepts / edits / rejects (human-in-the-loop)
- tests, CI, code review
- Completion: a small, fast code model (fill-in-the-middle) with sub-second latency; acceptance rate is the main quality signal.
- Chat and edits: a larger general or reasoning model with tool use (read file, grep, run tests); changes are applied as reviewable diffs.
- Context engineering: project rules files (e.g. AGENTS.md,
.cursorrules,copilot-instructions.md), repository indexing and the Model Context Protocol (MCP) to attach tickets, docs and databases. - Human-in-the-loop: the developer accepts each suggestion; commands and file writes need approval; the pull-request review stays mandatory (CODE-003).
Data preparation
A code assistant needs almost no classic data preparation, but its quality depends on the repository. The relevant material is source code in Git (GitHub, GitLab, Azure DevOps), READMEs and wikis in Confluence or SharePoint, and tickets in Jira. Typical gaps: outdated or missing documentation, secrets and credentials committed to the repo, generated or vendored code that pollutes the index, undocumented conventions that exist only in the heads of senior developers, and repositories with broad access rights that should not be indexed.
Preparation steps: (1) scan the repositories for secrets (gitleaks, GitHub secret scanning) and rotate what is found; (2) configure content exclusions for secrets, customer data and generated folders; (3) write a short rules file (AGENTS.md or CLAUDE.md) with build commands, architecture and conventions; (4) make sure tests and a linter run reliably, because they give the assistant feedback; (5) tidy README and architecture notes. Test data with real customer records must be pseudonymised first, see PREP-022. For internal documentation used as context, see PREP-013 and PREP-010.
Effort share: low, roughly 5 to 10 percent of the total. A day for secret scanning, exclusions and the rules file is usually enough to start; documentation clean-up improves results gradually.
Implementation paths
Which path for whom
- SMB: A - mature, EU-contractable assistants exist at per-seat prices and the use is standard, so a pilot is live within days.
- Enterprise: B - a BYOK client with a central gateway keeps model choice, budgets, logging and PII filtering under company control when seat costs scale.
- Developer: B - bring-your-own-key clients (Continue, Cline, Aider) let you pick the best model per task and pay only for usage.
- Public sector: C - source code and internal specifications stay in the own network, which also eases procurement and sovereignty requirements.
- Private: C - local tools such as Ollama or LM Studio with a coder model keep hobby and client code on your own machine at no running cost.
Path A — Buy (recommended)
- Assistants: GitHub Copilot (Business/Enterprise; EU data residency for inference available with GitHub Enterprise Cloud on ghe.com [4]), Cursor, Windsurf (renamed Devin Desktop by Cognition in June 2026), JetBrains AI Assistant / Junie (JetBrains is Czech-based, EU), Claude Code, Google Gemini Code Assist, Amazon Q Developer (IDE plugins end of support announced for April 2027, successor Kiro), Tabnine (EU-founded, offers private/air-gapped deployment), Sourcegraph Cody (enterprise-only since 2025) and Amp (spun out of Sourcegraph in Dec 2025), Mistral Code (EU, cloud, VPC or on-prem deployment [5]).
- Check: zero-retention and no-training terms, data residency, SSO/SCIM, audit logs, IP indemnity, public-code matching filter, content exclusion for secrets, MCP admin controls.
- Choose A when: you want productivity within days and can accept a vendor DPA; start with one tool and a pilot group.
Path B — Build on cloud APIs
- Models via API: Claude, GPT, Gemini families for chat and agentic edits; Mistral Codestral for completion and Devstral for agentic coding (EU provider) [5]; hosted in EU regions through Azure OpenAI, Amazon Bedrock or Google Vertex AI.
- Bring-your-own-key clients: Continue, Cline, Roo Code, Zed, Aider and Copilot BYOK let a team pick models and keep a gateway (LiteLLM, Portkey) for logging, budgets and PII filtering.
- Choose B when: you need model choice, cost control, a central proxy for compliance, or EU-only providers.
Path C — Self-host (open source)
- Models (open weights): Qwen3-Coder family, Devstral Small (24B, Apache 2.0) [5], DeepSeek-Coder/V3 family, Codestral-class FIM models (check licence terms), StarCoder2 and Granite Code for completion.
- Serving: vLLM, SGLang, llama.cpp or Ollama; embeddings with an open code-embedding model; clients: Continue, Cline, Tabby (self-hosted server), Void.
- Hardware: HW2 (one 24–32 GB GPU) serves a quantised ~30B coder model or fast FIM for a small team; for 50+ concurrent developers or the largest open agentic models plan HW3–HW4.
- Effort: a platform engineer to run serving, updates, evaluation and access control. Quality of small local models still trails frontier models on complex multi-file tasks.
- Choose C when: code must not leave the network (defence suppliers, public sector, trade secrets).
Path D — Custom training
Rarely worthwhile. Fine-tune a small FIM model on the company's code only for proprietary languages or frameworks (e.g. internal DSLs, ABAP, PLC dialects) with a few hundred MB to GB of clean, licence-cleared code; retrieval over the repository solves most cases without training.
State of the art (2026)
- From autocomplete to agents: most IDEs now ship an agent mode that plans, edits several files, runs tests and iterates, with rules files and MCP integrations. Autonomous background agents are covered in CODE-002.
- Benchmarks: SWE-bench Verified and its harder successors, LiveCodeBench and Terminal-Bench are the common yardsticks; vendors report high scores on SWE-bench Verified, but contamination and scaffold differences make cross-vendor comparison unreliable [6].
- Frontier and open models keep converging: open-weight coder models now cover many everyday tasks locally.
- Limits and failure modes: plausible but wrong code, hallucinated APIs and packages (supply-chain risk through "slopsquatting"), insecure patterns, outdated library versions, shallow understanding of large architectures, over-long diffs that are hard to review, and automation bias (accepting suggestions without reading). Productivity gains are strongest on boilerplate, tests, unfamiliar languages and small tasks, and weakest in mature, complex code the developer knows well [1].
- Security: prompt injection through repository files, issues or MCP servers can make an agentic assistant leak secrets or run commands; permission prompts, sandboxing and least-privilege tokens are essential.
Shared resources & combinations
- Same stack (llm-code + embedding-text + vector-db + agent-framework): CODE-002 autonomous agents, CODE-003 code review, CODE-004 test generation, CODE-006 documentation, CODE-021 refactoring and upgrades all reuse the same models, repository index and gateway.
- Upstream/downstream: CODE-015 requirements, CODE-013 database/SQL help, CODE-009 infrastructure-as-code; security scanning of generated code (SEC-001).
- Platform: one self-hosted inference server (HW2/HW3) or one API gateway can serve all developer-facing AI features and other internal RAG use cases.
Effort, cost & KPIs
- Path A: days to set up; per-seat monthly subscription, often with usage-based credits for premium models and agents.
- Path B: 2–6 weeks for gateway, logging and client rollout; cost scales with tokens, and agent modes consume much more than completion.
- Path C: 1–3 months; GPU server plus part of a platform engineer.
- KPIs: weekly active users, suggestion acceptance rate, lead time and cycle time, pull-request size and review time, change failure rate and rework (DORA metrics [3]), defect and vulnerability rate of AI-assisted code, developer satisfaction, cost per active developer. Avoid "lines of code" as a metric.
People & change
Involve management first (budget, AI policy, see GUIDE-007), then the development lead as process owner, IT and information security for accounts, SSO and content exclusions, and the data protection officer for the vendor contract (AVV, Art. 28 GDPR) and telemetry settings. Developers should be part of tool selection from the start; a pilot group of 5 to 10 volunteers from different teams gives honest feedback and acts as AI champions later (GUIDE-008, GUIDE-009).
Works council: depends. Many assistants log prompts, accepted suggestions and usage per user, so objective suitability to monitor behaviour or performance can trigger co-determination under section 87(1) no. 6 BetrVG; section 90(1) no. 3 requires timely information when work processes are planned with AI. A works agreement that excludes individual performance evaluation settles this quickly (GUIDE-004). In the public sector the staff council (Personalrat) is responsible.
AI literacy: since 27 Jul 2026 employers must take measures to support staff's AI literacy (Art. 4 AI Act); offer short sessions on prompting, reviewing generated code and licence/secret hygiene (GUIDE-006). Typical concerns are job loss, surveillance and code quality: state clearly that usage data is not used for appraisal, that every suggestion is reviewed by a human and that merges stay with developers.
Risks, regulation & compliance
- EU AI Act: minimal risk for general developer tooling; AI literacy duty (Art. 4) applies to staff using it. If generated code ends up in a high-risk system (e.g. medical, safety, credit scoring) the provider's quality-management and documentation duties apply to the final system, not the tool. Employee-monitoring use of IDE telemetry (productivity scoring of individuals) can touch Annex III employment rules and works-council co-determination in Germany (BetrVG §87).
- GDPR: prompts and code can contain personal data (test data, logs, customer records in snippets). Require a DPA, zero data retention, EU region where possible, and content exclusion for production data. Telemetry about individual developers is personal data.
- Intellectual property and licences: enable public-code matching filters, keep records of AI use, and follow the company policy on copyleft code; copyright protection for purely AI-generated code is uncertain in the EU. Check vendor IP indemnity.
- Security risks: secret leakage, prompt injection, malicious packages, over-privileged agents. Mitigations: SSO, secret scanning, sandboxed execution, allow-lists for MCP servers, mandatory code review and CI checks.
Getting started
- Write a short policy: allowed tools, data classes that may not be pasted, licence rules, review duty.
- Pilot one assistant with 10–20 developers for 4–6 weeks; capture a baseline (cycle time, review time, defects) before.
- Configure the safe defaults: zero retention, public-code filter, content exclusion, SSO, MCP allow-list.
- Add rules files per repository (build commands, conventions, forbidden patterns) to improve output quality.
- Compare against a Path C or EU-hosted option if sovereignty matters, then decide on rollout using measured results.
Sources
- METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- Peng et al. — The Impact of AI on Developer Productivity: Evidence from GitHub Copilot — https://arxiv.org/abs/2302.06590
- Google Cloud DORA — Research on AI-assisted software development — https://dora.dev/research/
- GitHub Docs — GitHub Copilot with data residency — https://docs.github.com/en/enterprise-cloud@latest/admin/data-residency/github-copilot-with-data-residency
- Mistral AI — Codestral 25.08 and the complete Mistral coding stack for enterprise — https://mistral.ai/news/codestral-25-08/
- SWE-bench — leaderboards and methodology — https://www.swebench.com/
- Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Continue — open-source AI code assistant — https://github.com/continuedev/continue