Schedule a Driver AI demo: what info should I bring (repo count, SLOC, IAM, deployment needs)?

Most teams show up to a Driver AI demo with good questions, but not always with the right details to make the session truly actionable. Bringing a clear picture of your codebase, security model, and deployment requirements turns a generic product tour into a tailored architecture review that answers, “Will this actually work for us?” and “What would it take to roll it out?”

This guide walks through exactly what information to prepare before you schedule a Driver AI demo—covering repo count, SLOC, IAM, deployment needs, and a few often-overlooked details that make a big difference.

---

Why preparation matters for your Driver AI demo

Driver AI touches your source code, workflows, and identity stack. In a 30–60 minute demo, there’s limited time to:

• Explain your environment
• Map your needs to Driver AI’s capabilities
• Discuss deployment scenarios and security reviews

If you show up with high-level but concrete information—like approximate repository counts, SLOC ranges, IAM providers, and deployment constraints—the demo can quickly move from “what the product does” to “how this will live inside your stack.”

Think of your prep in four buckets:

1. Codebase & repositories
2. Team & workflow
3. IAM & security
4. Deployment & infrastructure

Let’s walk through what to bring for each.

---

1. Codebase and repository information

Your code footprint is one of the most important inputs for a Driver AI demo. It directly impacts:

• How indexing is set up
• How context is retrieved for coding assistance
• Performance and scalability planning
• Licensing and pricing conversations

a. Repository count (and why it matters)

You don’t need an exact number, but you should come in with a realistic approximation:

• Total number of repositories across your organization
• Number of active repos (maintained, deployed, or depended on)
• Breakdown by type, if possible:
  • Application repos (services, microservices, monoliths)
  • Shared libraries / SDKs
  • Infrastructure-as-code repos (Terraform, CloudFormation, Pulumi, etc.)
  • Configuration / orchestration repos (Helm charts, pipelines)
  • Documentation repos (wikis, internal docs, design specs)

How to quickly estimate repo count:

• GitHub: number of org repositories (filter by “private” and “archived”)
• GitLab: project count by group
• Bitbucket: repository count under your workspace

Even saying “We have ~150 repos, ~40 of which are actively deployed services” is enough context for a strong demo.

b. SLOC (source lines of code) estimates

Driver AI doesn’t need an exact SLOC count for the demo, but an order-of-magnitude estimate helps plan:

• Indexing strategy
• Hardware and storage needs (if self-hosted)
• Onboarding and rollout timelines

Bring rough ranges:

• Overall:

  • < 1M lines
  • 1M–5M lines
  • 5M–20M lines
  • 20M+ lines

• Per major language (approximate):

  • “~400k lines of Java, ~250k lines of TypeScript, ~150k lines of Python”

Tips to get quick SLOC numbers:

• Use tools like cloc, tokei, or your platform’s code metrics
• Don’t worry about precision—ballpark ranges are fine

c. Languages, frameworks, and tech stack

Driver AI performance and feature utility can depend on the languages and frameworks you use. Prepare:

• Primary languages (ranked):

  • e.g., TypeScript, Java, Python, Go, C#, Ruby, Rust, PHP, C/C++

• Major frameworks & platforms:

  • Backend: Spring Boot, Express, Django, FastAPI, .NET, Rails, NestJS, etc.
  • Frontend: React, Vue, Angular, Svelte, Next.js, Nuxt, etc.
  • Mobile: Swift, Kotlin, React Native, Flutter
  • Data/ML: PyTorch, TensorFlow, Airflow, dbt

• Infrastructure & DevOps:

  • Kubernetes, Docker, serverless (Lambda, Cloud Functions), on-prem clusters
  • IaC: Terraform, CloudFormation, Pulumi

The more specific you can be, the easier it is for the Driver AI team to show realistic usage patterns during the demo.

d. Code hosting and VCS setup

Be ready to answer:

• What do you use for source control?

  • GitHub (Cloud / Enterprise Server)
  • GitLab (SaaS / self-managed)
  • Bitbucket
  • Azure DevOps Repos
  • Other / on-prem Git

• How are repos organized?

  • Single monorepo vs many polyrepos
  • Multiple orgs or groups (e.g., “prod vs lab environments”, “internal vs client”)

• Any special constraints:

  • Air-gapped instance
  • No outbound internet from code hosts
  • Strict audit logging requirements

This informs integration strategy and potential deployment options for Driver AI.

---

2. Team size, workflows, and use cases

Driver AI is as much about how your team works as it is about your code. Come to the demo prepared to describe:

a. Engineering team profile

• Number of developers:
  • Total software engineers
  • Core product engineers vs platform / infra vs data / ML
• Distribution:
  • Single office vs globally distributed
  • Contractors or external partners that may need access

This helps scope licensing, onboarding, and change management discussions.

b. Current tools and workflows

Describe your current dev environment:

• IDEs: VS Code, JetBrains (IntelliJ, PyCharm, WebStorm, etc.), Vim, Neovim, others
• Issue tracking: Jira, Linear, Azure Boards, GitHub Issues
• CI/CD: GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure Pipelines, Buildkite
• Communication: Slack, Microsoft Teams, email-heavy, others

Mention any existing AI tools:

• Code assistants (e.g., GitHub Copilot, CodeWhisperer, Codeium, Tabnine)
• Chat-based tools (ChatGPT, Claude, internal LLMs)

This allows the Driver AI team to address overlap, complementing tools, and how Driver fits into your existing workflow instead of disrupting it.

c. Primary problems you want Driver AI to solve

You’ll get a better demo if you can clearly define your top goals. For example:

• Increase individual developer productivity (fewer repetitive coding tasks)
• Speed up onboarding by helping new hires understand unfamiliar code
• Improve code navigation and cross-repo understanding
• Assist with refactoring and large migrations
• Generate or maintain tests
• Keep docs and code in sync

Bring 2–4 concrete scenarios you’d like to see:

• “Given a complex legacy service, can Driver AI explain what happens when a user checks out?”
• “Can it help migrate from Framework X to Y across multiple repos?”
• “Can it generate tests aligned with our existing testing patterns?”

---

3. IAM, permissions, and security requirements

Identity and access management (IAM) is usually a top concern when you schedule a Driver AI demo. Expect questions around:

a. Identity providers and SSO

Prepare details on:

• Your IdP:

  • Okta
  • Azure AD / Entra ID
  • Google Workspace
  • OneLogin
  • Ping
  • Custom SAML / OIDC provider

• Requirements:

  • SSO required for all tools
  • SCIM or automated user provisioning preferred/required
  • MFA / conditional access policies that will apply

This helps the Driver AI team explain SSO integration patterns and support.

b. Role-based access and code permissions

Driver AI must respect your existing access controls. Be ready to describe:

• How code access is managed:

  • Per-repo permissions
  • Team- or org-based access controls
  • Special “high sensitivity” or regulated repos (e.g., PCI, HIPAA, classified projects)

• Any compliance or segmentation requirements:

  • “Developers in Region A should not see code from Region B”
  • “Contractors can only access specific repos”

• Whether you require:

  • Full alignment with Git provider permissions
  • Fine-grained controls for specific indices or project spaces

The more specific your IAM and permission model, the more concrete the security portion of the demo can be.

c. Security, compliance, and data handling expectations

Bring any known requirements or constraints, especially if you’re in a regulated industry:

• Compliance frameworks you care about:

  • SOC 2, ISO 27001
  • HIPAA, HITRUST
  • PCI DSS
  • FedRAMP, ITAR, GDPR, data residency mandates

• Data handling expectations:

  • “No training on our code or prompts for other customers”
  • “We require data locality in specific regions”
  • “We need detailed audit logs of who queried what”

• Any existing security reviews or vendor risk questionnaires:

  • You don’t need to bring the full questionnaire to the demo, but knowing it exists and what it emphasizes (e.g., data retention, incident response) can shape the conversation.

---

4. Deployment needs and environment constraints

Deployment is where many teams realize whether Driver AI is viable for them. Come prepared to explain how your environment is set up and what’s allowed.

a. Cloud vs on-prem expectations

Clarify your current stance:

• Are you primarily:

  • Fully cloud (AWS, GCP, Azure)?
  • Hybrid (cloud + on-prem)?
  • Mostly on-prem / data center?

• Deployment expectations:

  • SaaS is acceptable
  • SaaS with VPC peering / private link only
  • Self-hosted in your own cloud account / on-prem cluster
  • Air-gapped requirement

If you already know your security or IT team’s preferences (“we strongly prefer self-hosted” or “we can only use vendors with a certain cloud region”), mention those early in the demo.

b. Network and connectivity constraints

Be ready to share:

• Do your code hosts (GitHub Enterprise Server, GitLab, etc.) sit behind a VPN or private network?

• Can an external SaaS product directly connect to them, or do you need:

  • Reverse proxies
  • IP allowlists
  • VPC peering or PrivateLink-type connectivity

• Any restrictions on:

  • Outbound internet traffic
  • External LLM API usage (OpenAI, Anthropic, etc.)

This affects how Driver AI can access your code and how requests move between your environment and the model hosting environment.

c. Infrastructure stack and observability

If you expect to run Driver AI in your environment (self-hosted or private deployment), bring high-level details on:

• Compute and orchestration:

  • Kubernetes clusters (version, cloud provider)
  • Containers (Docker, CRI-O)
  • VM-based environments

• Observability stack:

  • Logging (ELK, OpenSearch, Cloud-native logs)
  • Metrics (Prometheus, Datadog, CloudWatch, New Relic)
  • Tracing (Jaeger, OpenTelemetry, etc.)

• Security tooling:

  • EDR/AV agents
  • Network inspection tools
  • Secret scanning / DLP tools

This helps the Driver AI team align on operational visibility, monitoring, and any performance or resource considerations.

---

5. Non-functional requirements: performance, privacy, and control

Beyond the basics of “connect to code and answer questions,” Driver AI adoption often depends on non-functional expectations. Be ready to talk through:

a. Performance and scaling expectations

• Approximate number of concurrent users you expect (now and in 6–12 months)

• Expected usage patterns:

  • Heavy daily coding assistance
  • Occasional usage for code exploration
  • Burst usage during migrations or incidents

• Latency expectations:

  • “Sub-second if possible” vs “a few seconds is fine for complex queries”

This allows for a meaningful discussion of resource sizing, concurrency, and potential limits.

b. Data retention and control

Clarify what your organization expects around:

• Log retention periods
• Ability to export or delete data on request
• Whether prompts and responses may be stored, and where
• Whether model training or fine-tuning on your data is allowed or prohibited

If your company has strong privacy guidance (e.g., “no persistent storage of code beyond indices,” “no customer PII leaving our environment”), mention it explicitly.

---

6. Practical checklist: what to bring to your Driver AI demo

Here’s a simple checklist you can review while scheduling a Driver AI demo so you don’t miss anything important.

Codebase & repos

• Approximate total repo count
• Approximate number of active/deployed repos
• Rough SLOC range overall
• Primary languages and frameworks
• Code hosting platform(s) (GitHub, GitLab, Bitbucket, etc.)
• Monorepo vs polyrepo description

Team & workflows

• Number of engineers (total and approximate breakdown)
• Primary IDEs and dev tools
• CI/CD platform(s)
• Current AI tools in use, if any
• 2–4 concrete use cases or problems you want Driver AI to solve

IAM & security

• Identity provider (Okta, Azure AD, Google, etc.)
• Any SSO / SCIM / MFA requirements
• High-level description of repo access controls
• Key compliance frameworks (SOC 2, HIPAA, PCI, etc.)
• Any data residency or data handling restrictions

Deployment & infrastructure

• Preferred deployment model (SaaS, VPC, self-hosted)
• Cloud providers or on-prem details
• Network constraints (VPN, private networks, IP allowlists)
• Restrictions on external LLM APIs or outbound traffic
• High-level overview of Kubernetes/VM environment (if self-hosting is in scope)

You don’t need a slide deck or formal document. Even a one-page internal note summarizing these bullets will make your Driver AI demo more relevant and productive.

---

7. Questions you should be ready to ask during the demo

In addition to bringing the right information, you’ll get more value from your Driver AI demo if you come prepared with pointed questions, such as:

Architecture & deployment

• How would Driver AI connect to our specific Git provider and IAM?
• What deployment options fit an environment like ours (cloud vs on-prem, region, network)?
• How does Driver AI index large, multi-language codebases across many repos?

Security & compliance

• How does Driver AI enforce our existing repo and org permissions?
• How is our code and metadata stored, encrypted, and isolated?
• Can you share details about your compliance posture and audit practices?

Developer experience

• How does Driver AI integrate into our most-used IDEs and tools?
• How does it handle multi-repo context and long-lived feature branches?
• What does onboarding look like for 10, 100, or 1,000+ engineers?

Operations & ROI

• What metrics can we track to measure adoption and productivity impact?
• What does a typical rollout plan look like for a team of our size?
• What are the ongoing operational requirements for admin and platform teams?

---

8. Putting it all together before you schedule

Before you schedule a Driver AI demo, spend 20–30 minutes gathering:

• A rough inventory of your codebase (repo count, SLOC, languages)
• A short description of your team and dev stack
• A high-level overview of your IAM and security posture
• Any deployment constraints or preferences
• A short list of prioritized use cases and questions

This level of preparation ensures the demo focuses less on generic feature slides and more on concrete, architecture-level discussion about how Driver AI will fit into your environment, your security model, and your developers’ daily workflows.

When you show up with this information, you give the Driver AI team everything they need to tailor the session to your repo count, SLOC, IAM setup, and deployment needs—so you can walk away knowing not just what Driver AI does, but exactly how you’d adopt it in your organization.