In custom development, baseline assumptions about the development environment vary entirely by project. On one project, teams use coding agents as a matter of course; on another, the contract explicitly forbids sending source code to external services. Finance, healthcare, the public sector, and parts of manufacturing—these conditions are far from rare.
The problem is that productivity on that specific project gets left behind in the past. In the same week, the same team might have AI handle refactoring on one project while hand-writing everything on another. This gap directly impacts both cost estimates and delivery schedules.
A coding agent that runs entirely locally
In August 2026, JetBrains launched Junie Local. It is positioned as a locally executed edition of the company's Junie coding agent.
Reported specifications are as follows:
| Item | Details |
|---|---|
| Operating environment | Runs entirely on the local machine. No API or model usage fees |
| Model | 4-bit quantized Qwen3.6-27B. Download size approx. 20 GB |
| Required specs | M5 Mac with 64 GB RAM |
| Implementation method | Simply run the /local command inside Junie. No token or quota configuration needed |
| Roadmap | Support for NVIDIA RTX 5909 is currently in development |
Regarding model selection, JetBrains explained that they intentionally chose Qwen3.6 over the newer Qwen3.8. The reason is task execution speed; in local execution, latency directly dictates usability. For a product designed to run locally, this is a sensible decision.
While Publickey reported performance comparable to Claude Sonnet 4.5, this is vendor-reported benchmarking and may not reproduce as-is on your own codebase. If you plan to adopt it, make your evaluation using actual project code first.
Confirming what "not sending outside" actually means
Before considering adoption, there is something you must clarify: what is actually prohibited by contract or internal policy. This differs considerably from project to project.
- If it is a prohibition on transmitting source code to external services, local execution satisfies the requirement
- If it is a prohibition on incorporating AI-generated code itself, whether it runs locally does not matter; it cannot be used
- If it stems from concerns over rights to deliverables, model licensing and the treatment of outputs must be reviewed separately
Adopting a tool under the assumption that the second or third scenario is actually the first will cause issues later. In our experience, the more a project verbally asserts that "AI is forbidden," the less likely what is prohibited has been confirmed in writing. Pin that down first.
Device specs directly become implementation costs
The requirement of an M5 Mac with 64 GB RAM is not trivial for a custom development team. If replacing everyone's machine becomes necessary, the advantage of zero license fees quickly diminishes.
A realistic approach is to limit deployment strictly to team members assigned to relevant projects. If projects prohibiting external transmission make up 20% of your portfolio, you only need to target machines for the members handling that 20%. Deciding to make it a company-wide standard can wait until supported hardware expands.
This structure mirrors the decision of whether to place AI inference on-premises. Running models locally is a choice driven by the constraint that data cannot leave the environment, not a choice made for performance or cost. There is little reason to deliberately choose it for projects without constraints.
Do not assume the same scope as cloud versions
Locally run models do not handle the same breadth with the same accuracy as cutting-edge cloud models. Expecting identical usage will lead to disappointment.
Tasks that succeed best in practice are those with self-contained inputs and outputs.
- Explaining existing code: local models are fully adequate for understanding unfamiliar modules
- Routine transformations: standardizing naming conventions, generating test code scaffolding, adding type definitions
- Self-checks before review: identifying obvious oversights or inconsistencies
Conversely, it is safer to lower expectations for tasks involving architectural decisions or reconciling consistency across an entire repository. Here, physical constraints on device memory come into play. When designing workflows around local execution, drawing the line on what to complete on-device is ultimately the most critical factor.
Confirming at the proposal stage changes everything later
In custom development, what proves most effective is confirming whether AI usage is permitted during the proposal and estimation phase. Discovering that tools cannot be used after signing a contract collapses estimated effort on the spot.
The points to verify are few. Confirming the following three items in writing regarding development tools is sufficient:
- Whether source code may be transmitted to external services
- If transmission is disallowed, whether entirely local tools are acceptable
- Whether deliverables require disclosure or reporting regarding AI involvement
This exchange does more than establish constraints for the team: it also gives clients the criteria needed to decide between an outright ban on AI and conditional approval. In practice, clients often respond that "it's fine as long as code doesn't leave for the cloud," and we frequently see projects that proceeded under total bans simply because nobody asked.
The same applies to cost estimates: discussions move faster when you present estimated effort under the assumption of AI availability alongside effort without it. Seeing the difference makes it easier for clients to relax restrictions.
What to do next
First, classify your ongoing projects based on whether external code transmission is prohibited. If none of your projects fall under a ban, you do not need to worry about this for now.
If you have projects that do, check where that restriction is written in the contract. If it reads as a "ban on transmitting to external services," local execution becomes a viable option. If it reads as a "ban on AI usage," you need to discuss it with the client first. Tool selection comes after that.
At GleamHub, our development, AI, and automation consulting assists with architecting AI utilization for confidential projects, configuring local execution environments, and integrating them into development workflows. Applicable configurations vary depending on project constraints, so please reach out for an individual consultation via Contact Us.
