AI can help developers write code and can power features such as text generation and speech processing. At GeekyAnts, these uses involve different tools and different questions about data access, provider terms, and client requirements.
Engineering assistants such as Claude Code help developers work with code and project documentation. Application model providers, such as Gemini or Claude, can power features within a product. This distinction is important, as the coding assistant may interact with a repository, while an application model may process user input or generate content.
Choosing a tool therefore starts with its intended use and the information it needs to handle. The team must also consider security requirements, provider data practices, or any other restriction set by the client. These factors help determine which tools fit a project and which safeguards it needs.
Which AI Tools and Model Providers Do GeekyAnts Use?
The projects covered in this series use different tools for engineering work and AI features inside applications. Claude Code is the primary engineering assistant across these projects. Some engineers also use Cursor, OpenAI Codex, and opencode, subject to repository-level rules. These examples describe documented usage rather than a confirmed company-wide list of approved tools.
Application AI features use a separate set of model and speech-processing options. The documented projects include Gemini, Claude, OpenAI, OpenRouter, and locally hosted models through Ollama. Speech-related options include Gemini and Whisper for speech-to-text, and Kokoro for text-to-speech. The options serve different purposes and are not necessarily used together in one product. Engineering agents can also connect to tools such as Figma, Playwright, Jira, and component registries through the Model Context Protocol (MCP).
The three projects illustrate these differences:
- Clinical education platform: Gemini handles production AI requests. The platform also supports adapters for Claude, OpenAI, OpenRouter, and Ollama, providing alternative provider options at the application level.
- Family-records app: Claude is the default for text generation, while Gemini is the default for speech-to-text. The project also includes alternative model-provider options through OpenAI, OpenRouter, and Ollama, with Whisper and Kokoro among its documented speech-related options.
- ga: GeekyAnts’ internal engineering assistant runs on Claude and helps turn project documents into a cited knowledge base and working application code within a Next.js, Expo, and NestJS monorepo.
- ga-stack: This internal reference tool provides project-specific instructions for technologies such as Next.js, Expo, NestJS, and Prisma. It is enabled on a per-project basis.
These examples show what the documented projects use, not a guarantee that every provider is available for every client. Tool selection depends on the task, the data involved, and the project’s requirements.
How Does GeekyAnts Assess AI Providers and Approve Their Use?
Before choosing an AI tool, the team needs to understand what it will handle. A coding assistant may access source code and project documentation, while an application model may process user input, transcripts, or generated content. The team can then assess whether an external provider fits the use case or whether a local model is worth considering.
Provider terms should be assessed for data retention, model-training use, processing location, and subprocessors. These conditions can vary by provider and plan, so the relevant terms must be evaluated against the client’s security requirements and contractual obligations.
How Do Repository Rules and Human Review Govern AI Tool Use?
Engineering safeguards also set boundaries on what an assistant can do. In the documented projects, repository-level rules govern AI-assisted work, and human review remains part of the process. Permission to help write code does not automatically mean permission to access every sensitive file or carry out consequential actions without review.
Tool selection should account for project-specific risks, provider terms, data access, and repository-level safeguards. Any company-wide approval or vendor-review process should be described only in terms of a verified policy.
How Are Data Retention, Subprocessors, and Hosting Handled?
The ga workflow allows confidential client documents to remain on the engineer's machine rather than being committed to a repository. However, any content sent to an external AI model is processed as per the provider's data-handling terms. Access to sensitive files needs to be controlled, and confidential documents require a project-specific decision about whether they belong in version control or should remain local. Files exported from tools such as Postman or Insomnia may contain access tokens, so they should be cleaned before being shared or kept local when appropriate.
Data retention depends on the application’s requirements and the reason information needs to be retained. In the clinical education platform, the documented AI logging setup stores full call content in the client's own database and cloud account, allowing interactions to be reviewed when an assessment score is disputed. Logging can be enabled or disabled depending on the environment. For the family-records app, audio is not retained, transcripts and drafts are deleted 24 hours after a session ends, and logs are redacted to limit the exposure of sensitive information. These practices describe this project and should not be interpreted as standard retention practices across GeekyAnts.
These examples show why retention periods and logging practices need to reflect each project’s data, purpose, and requirements.
How Does AI Hosting, Data Processing, and Subprocessors Affect Data Handling?
External AI providers and connected services affect where information is processed and which parties may handle it. Before selecting an arrangement, teams should review the relevant provider terms, subprocessors, retention conditions, and processing locations. The subprocessors relevant to the engagement should also be identified and confirmed.
Hosting choices affect where AI processing takes place and which services handle the data. The documented projects use provider-hosted models and include local model options through Ollama. Google Vertex AI supports region selection, while Ollama and Kokoro can support self-hosted deployments. Claude Code can be used through Anthropic’s API, Amazon Bedrock, or Google Vertex AI, depending on the configuration. However, selecting a region does not automatically guarantee that all data processing and storage remain within that region. These arrangements depend on the provider, model, deployment configuration, and contractual terms.
The practical question is how these decisions fit together. A team handling sensitive health information may need different retention and hosting arrangements from one building a general-purpose consumer app. Reviewing the data, provider terms, and deployment requirements together helps clients understand what will be stored, where processing takes place, and which parties may handle their information.
Can Clients Restrict AI Tools or Require Private or Regional Deployment?
Clients may need to restrict AI use to named tools or providers, limit which services can process their data, or explore private and regional deployment options. These requirements should be discussed before the architecture is finalized so that the proposed tools, data flows, provider capabilities, and contract terms can be evaluated against the client’s needs.
Three considerations help clarify the available options:
- Documented capabilities: The projects covered in this series use provider-hosted models and include local model options through Ollama. These examples demonstrate technical approaches, but their suitability depends on each project’s requirements.
- Requirements to evaluate: Teams should assess restrictions on specific tools or providers, data-processing locations, and private or regional hosting needs against the proposed architecture and provider terms.
- Options requiring confirmation: Any commitment to exclude AI, restrict usage to named providers, or provide private or region-specific hosting must be verified for the individual engagement. These options should not be presented as standard offerings without confirmation.
The proposed tools, data-handling practices, and deployment options must meet the client’s security, operational, and contractual requirements.
Conclusion
AI adoption requires decisions that account for evolving tools, client requirements, and security needs. As model capabilities evolve, GeekyAnts must evaluate new options while considering their effects on the software, the data it processes, and the client’s ability to define boundaries.
The aim is to make AI adoption a deliberate engineering decision, with clear data-handling expectations and the flexibility to adapt as client needs evolve.
