The Technical Foundation of Privacy-First AI Engineering
AI is becoming part of the software development environment. WhoseDev is built around a simple question: how powerful can AI become without requiring developers to give up control of their code, credentials, and development environment?
This is the technical reasoning behind WhoseDev, including its privacy architecture, local processing model, model flexibility, agentic workflows, and the engineering problems we believe deserve a different approach.
AI Coding Is Powerful. The Data Pipeline Matters.
Modern AI coding systems can understand source code, explain architecture, generate tests, refactor applications, investigate bugs, and increasingly perform multi-step engineering tasks. This is one of the most important changes to software development since the arrival of modern development environments.
But AI assistance introduces a new architectural dependency. Software development environments contain valuable information, and AI systems need context to be useful.
That context can include source code, project structure, stack traces, configuration files, dependency information, internal identifiers, environment variables, credentials, and developer instructions.
The fundamental question is therefore not simply: “Which model is smartest?”
A second question matters just as much: “What information does that model need to receive in order to be useful?”
WhoseDev is built around the belief that these two questions should be separated.
Intelligence should be flexible. Data control should belong to the developer.
The AI Coding Problem Is Not Just About Model Intelligence
The more capable coding agents become, the more context they can potentially access. That creates a second engineering problem: controlling the boundary between the development environment and the AI system.
Context Exposure
AI systems often become more useful as they receive more relevant context. More context can also mean more sensitive information becomes available to the model or the service operating it.
Infrastructure Dependence
Cloud models provide enormous capabilities, but using them can introduce another external dependency into the software development environment.
Agentic Access
As AI agents gain the ability to inspect files and perform actions, permissions and boundaries become just as important as model quality.
This Is Already a Recognized AI Security Problem
WhoseDev is not based on the assumption that AI privacy risks are theoretical. Security organizations are actively documenting these risks.
The OWASP Top 10 for Large Language Model Applications identifies sensitive information disclosure as a major risk category. Sensitive information can include confidential business data, security credentials, proprietary algorithms, personal information, and other data that should not be exposed unnecessarily to an AI system.
OWASP also identifies excessive agency as a risk. An AI system that can perform actions needs appropriate controls around what it is allowed to access and what it is allowed to do.
These concerns become particularly relevant when AI moves from simple question answering toward agentic software development. An AI that can inspect a repository, modify files, execute commands, and iterate over a task has a fundamentally different security boundary from an AI that only returns text.
NIST's Generative AI Risk Management Profile similarly treats generative AI as a technology that requires deliberate risk management across its lifecycle. The objective is not to avoid AI. It is to understand its risks and introduce appropriate controls.
Sensitive Information Disclosure
AI applications can expose sensitive information through prompts, context, outputs, or application behavior. Data sanitization is one of the approaches recommended to reduce unnecessary exposure.
Excessive Agency
Giving AI systems excessive authority can create security and reliability problems. Agentic systems therefore need meaningful boundaries around their available actions.
Privacy Is a Pipeline Problem
WhoseDev approaches privacy at the point where developer context becomes AI context.
Workspace
The developer works inside the local editor and creates a task.
Context Layer
Relevant workspace information is assembled and processed locally.
Model Layer
The request is routed to a local model or selected external provider.
Response Layer
The client interprets the response and manages the resulting change.
Five Principles Behind WhoseDev
Process Sensitive Context Locally
Privacy-sensitive processing should happen as close to the source as practical. The local client is therefore positioned as an important control point between the workspace and external AI services.
Send Only What the Task Needs
A useful AI request does not automatically require an entire repository. Context selection should be driven by the task and the information required to solve it.
Separate Intelligence From Infrastructure
The editor should not need to depend on one model provider forever. Local models and external providers should be execution choices rather than permanent architectural commitments.
Keep the Developer in the Loop
Agentic automation should increase productivity without turning the AI into an unrestricted process. Permissions, confirmations, and workspace boundaries matter.
Make Privacy a Technical Property
Privacy should not exist only as a statement in a policy document. The software architecture itself should provide meaningful mechanisms for controlling data exposure.
The Editor Should Decide What the AI Needs to Know
Better AI coding is not simply about sending more tokens. It is about supplying the right context.
Relevant Context
- +Active file
- +Relevant code selection
- +Project relationships
- +Language and framework context
- +User instructions
Context That May Need Protection
- +Credentials
- +Internal endpoints
- +Private identifiers
- +Environment-specific values
- +Unnecessary repository context
Masking Is About Reducing Exposure Without Destroying Context
One of the central challenges in privacy-aware AI coding is that useful AI requires context. Simply deleting everything sensitive can make the model unable to understand the task.
A context-protection system can instead transform selected sensitive values into deterministic or temporary representations while preserving their role within the surrounding code.
The model can still understand that the variable represents an endpoint and can reason about how that value is used. The original value can remain available to the local application where it is actually needed.
This approach has an important limitation: masking is not equivalent to perfect information hiding. Models can infer information from surrounding context, and not every sensitive value can necessarily be detected or transformed correctly. That is why WhoseDev treats masking as one layer in a broader privacy architecture rather than a universal security guarantee.
Your Code Does Not Always Need to Leave Your Machine
Local inference creates a fundamentally different deployment model for AI-assisted software development.
Ollama & Local Model Servers
WhoseDev can connect to local model infrastructure such as Ollama and compatible local endpoints. This makes it possible to build workflows where model inference happens inside the developer's environment.
- Local inference can keep model requests inside the local environment.
- Useful for disconnected or tightly controlled development environments when the necessary components are installed.
- Reduces dependence on external inference services.
- Allows developers to experiment with locally available models and model sizes.
Bring Your Own Model Access
Developers may prefer hosted models because of their capability, speed, context windows, or specialized features. WhoseDev is designed to support that reality rather than pretending local models will always be the best option.
- Use the model provider appropriate for the task.
- Maintain control of provider credentials where supported.
- Apply local context handling before external transmission.
- Switch providers as the model ecosystem evolves.
The Next Interface Is Not a Chat Box
The future of AI-assisted development is moving toward systems that can reason across a task, inspect relevant context, propose changes, execute actions, and verify results.
Understand Before Acting
The agent considers the task and relevant workspace context before attempting to modify the project.
Resolve Ambiguity
When an important decision is unclear, the developer can remain part of the decision process rather than allowing the agent to invent assumptions.
Execute and Verify
The agent can generate or modify code and use available development tooling to help validate the result.
Why agent permissions matter
An AI agent that can act is fundamentally different from an AI assistant that only answers questions. The more authority an agent receives, the more important its boundaries become. Workspace scope, file access, tool permissions, confirmation points, and execution policies should therefore be treated as first-class engineering concerns.
What Happens When You Ask WhoseDev to Change Your Code?
The exact implementation depends on the configured model and feature, but the architectural concept is straightforward.
The developer creates a task
The developer asks WhoseDev to explain, generate, refactor, debug, test, or modify software.
Relevant context is assembled
The client determines which available workspace information is relevant to the request.
Local privacy processing occurs
The local layer can identify sensitive information and apply the configured context-protection strategy.
The request is routed
The request is handled by the selected local model or external model provider.
The model reasons over the request
The selected model generates an explanation, completion, patch, plan, or other response.
The response returns to the client
The editor receives the model output and determines how it should be presented or processed.
Local processing completes the workflow
Where applicable, the client interprets protected context, prepares changes, and presents the developer with the result.
Privacy Cannot Become an Excuse for a Slow Editor
Developers interact with their editor continuously. Every additional processing step therefore has a cost. Context analysis, sensitive-value detection, token transformation, and request preparation all need to be engineered with latency in mind.
WhoseDev's local privacy pipeline is designed to minimize this overhead so that privacy processing remains an invisible part of the development workflow rather than becoming another obstacle.
Publish as a verified benchmark only when reproducible testing confirms the figure for the deployed implementation.
We Are Not Trying to Win by Having One More Chat Window
The opportunity is bigger than another AI assistant.
The Conventional Question
“Which AI model should I use?”
Models improve rapidly. A model that leads today can be replaced tomorrow.
The WhoseDev Question
“How should my development environment control AI?”
That architectural question remains relevant regardless of which model becomes the best one next year.
Your Editor Should Outlive Any Single Model
The AI model ecosystem changes faster than most software infrastructure. A developer environment should be able to evolve with it.
Today, a developer may prefer one model for reasoning, another for code generation, another for speed, and a local model for sensitive workloads.
Tomorrow, those preferences may change completely.
WhoseDev is designed around model flexibility so that the development environment remains valuable even as the underlying model landscape changes.
The editor is the product. Models are capabilities.
That distinction is important. It means WhoseDev can focus on the developer experience, privacy architecture, context management, agent orchestration, and tooling while allowing the underlying intelligence layer to evolve.
We Would Rather Tell You the Truth Than Sell You a Fantasy
No responsible AI company should claim that a client-side privacy layer makes a system perfectly secure. Software security does not work that way.
A local privacy architecture can reduce unnecessary data exposure. It cannot guarantee that every secret will always be detected. It cannot guarantee that a model will never infer information. It cannot secure a compromised operating system. It cannot change the policies of an external model provider.
These limitations are not weaknesses in the idea. They are the reason the architecture needs multiple layers.
What WhoseDev can help control
- What context enters an AI request
- Local versus remote inference
- Model-provider selection
- Sensitive-value transformation
- Agent workspace boundaries
- Developer approval points
What still requires broader security controls
- Operating-system security
- Credential management
- Organization-wide access control
- Third-party infrastructure policies
- Compliance programs
- Developer security practices
Privacy Becomes More Valuable as the Codebase Becomes More Valuable
A personal project and a financial institution do not have the same risk profile. The architecture should be able to support both without pretending they are identical.
Individual Developers
Keep personal projects, private repositories, credentials, and development workflows under greater local control while still benefiting from modern AI assistance.
Startups
Protect proprietary product logic and intellectual property while giving small engineering teams access to increasingly capable AI development workflows.
Enterprise Teams
Build AI-assisted workflows around explicit data boundaries, provider choices, internal policies, and organizational security requirements.
Privacy by Architecture, Not by Promise
A privacy policy describes how a company says it handles information. Architecture determines what the software is designed to expose, process, store, or transmit.
WhoseDev focuses heavily on the second problem.
The objective is to make data control part of the actual development workflow. Local processing, context selection, protected representations, model routing, local inference, and agent permissions are architectural decisions that can influence the amount of information exposed during AI-assisted development.
The principle
The safest piece of data is often the piece of data that never needed to leave the device.
The Value Is Not Just Faster Code
WhoseDev is designed to provide value across productivity, control, flexibility, and the long-term economics of AI-assisted development.
More Control
Choose where inference happens and which model infrastructure your workflow depends on.
More Privacy Options
Use local processing and local inference when your development environment requires stronger control over data exposure.
More Model Freedom
Avoid designing your entire development environment around one model vendor.
More Agent Control
Move toward autonomous workflows while keeping permissions, workspace boundaries, and developer decisions visible.
More Ownership
Your development environment remains the place where the work happens rather than becoming merely a front end for somebody else's AI infrastructure.
More Future Flexibility
As models improve, the editor and privacy architecture can continue evolving without requiring the entire development workflow to be rebuilt.
Frequently Asked Questions
Does WhoseDev require a cloud AI provider?
No. WhoseDev is designed to support local model workflows as well as external model providers. The appropriate configuration depends on the developer's requirements.
Can WhoseDev work offline?
A fully offline workflow is possible when the required WhoseDev functionality, model, dependencies, and supporting services are available locally. Cloud-based capabilities obviously require network connectivity.
Does masking mean the model cannot see my code?
No. Masking is not the same as hiding the entire codebase. Useful source code and context may still be provided to the model. The purpose is to reduce exposure of selected sensitive information while preserving useful context.
Does masking guarantee that every secret is protected?
No. Secret detection is not perfect, and sensitive information can appear in many forms. WhoseDev should be treated as a privacy layer, not as a replacement for secure development practices.
Can I use different AI providers?
WhoseDev is designed around provider flexibility, including local inference and external providers through supported integrations and developer-controlled credentials.
Does WhoseDev guarantee GDPR or SOC 2 compliance?
No. Compliance depends on the complete product, organization, infrastructure, policies, contracts, controls, and applicable legal requirements. WhoseDev's architecture can support stronger data-control practices, but it does not independently create compliance.
What happens when I use a cloud model?
The external model provider processes the information included in the request according to its applicable service terms, privacy controls, retention policies, and configuration. WhoseDev's local privacy architecture is designed to reduce unnecessary exposure before transmission, but it cannot change the provider's infrastructure or policies.
Why not just use a normal AI coding assistant?
You can. WhoseDev exists for developers who want another architectural choice, particularly developers who care about local processing, model flexibility, context control, provider independence, and privacy-aware agentic workflows.
AI Should Work for the Developer, Not the Other Way Around
The most important thing about an AI development environment is not how impressive its demo looks.
It is whether developers can trust the environment enough to make it part of their daily work.
Trust comes from understanding what the system can access, where processing happens, which services receive information, what the developer can control, and what happens when the AI begins taking actions instead of simply answering questions.
WhoseDev is built around that philosophy.
Build with the best AI available.
Run locally when you need to.
Choose your model.
Control your context.
Keep your development environment yours.
That is the direction we believe AI-assisted engineering should move toward.
Build With AI. Keep Control.
Experience an AI-assisted development environment designed around local processing, model flexibility, privacy-aware context handling, and developer-controlled agentic workflows.