G-Code for DevOps
The Azure Boards assistant your platform team runs and your security team can verify. GeekIt is never in the data path.
G-Code breaks epics into child work items and drafts thin tickets in your organisation's own house style. Nothing is written to Azure DevOps until a person approves it.
Four things to know first
What it does
You self-host it
You self-host it
A work item chat panel for Azure Boards, reached from a tab called AI Assistant. It reads the open work item and, where your admin enables it, the related source code. It proposes field edits and child work items shaped by your organisation's own curated skills library, and writes nothing to Azure DevOps until you review and approve it.
You self-host it
You self-host it
You self-host it
Your own platform team deploys it into your own Azure subscription. There is no vendor-hosted instance, no vendor-run endpoint and no vendor tenant anywhere in the path.
You supply your own inference capacity
On the Foundry path, content never leaves your tenant
On the Foundry path, content never leaves your tenant
Point it at your own Microsoft Foundry deployment or your own Anthropic account. Both are first-class, supported choices for different situations. Neither is a lesser version of the other.
On the Foundry path, content never leaves your tenant
On the Foundry path, content never leaves your tenant
On the Foundry path, content never leaves your tenant
That is true when you use your own Foundry deployment, inside your own Azure tenant and cloud agreement. It is a property of the path you choose, not of the product as a whole: on the Anthropic path, content leaves your tenant and reaches Anthropic. The comparison below sets out both.
GeekIt is never in the data path. Check it yourself.
GeekIt hosts nothing in G-Code's path.
No work item content, source code, prompts, model output, user identity or usage counts reach any system GeekIt controls, on either inference path: not at install, not during use, not at licence renewal. The only thing we ever receive is what you choose to send us, for example in a support email.
There is no telemetry.
No analytics, no crash reporter, no usage reporting. GeekIt doesn't resell or meter your inference either. Your own provider bills you for it.
The licence is checked offline, inside your own tenant.
It is checked against a public key already in the deployment. Nothing calls GeekIt, or any licensing authority, at install, at runtime or at renewal.
You don't have to take this on trust.
Run a network inspection at install, in normal use or during a renewal. The expected result is that there is no call to GeekIt to find.
Two ways to supply inference capacity, stated plainly
Microsoft Foundry (the default)
Microsoft Foundry (the default)
Microsoft Foundry (the default)
What it needs: an existing Microsoft Foundry model deployment.
Setting it up: a Foundry deployment, a quota request and an Azure AI capacity approval.
Where content goes: it stays inside your own Azure tenant and existing cloud agreement.
Billing: on your existing Azure agreement.
A. No customer content, identity or usage data reaches any endpoint GeekIt controls: True.
B. "Content never leaves your tenant": True on this path.
C. No long-lived provider credential anywhere: True on managed identity only.
Anthropic
Microsoft Foundry (the default)
Microsoft Foundry (the default)
What it needs: an Anthropic account and an API key.
Setting it up: none of the Foundry steps. The lowest bar to evaluate the product.
Where content goes: it leaves your tenant and reaches Anthropic, under Anthropic's own terms.
Billing: a separate Anthropic account and invoice.
A. No customer content, identity or usage data reaches any endpoint GeekIt controls: True. Anthropic is not GeekIt.
B. "Content never leaves your tenant": False on this path.
C. No long-lived provider credential anywhere: False. A key exists, in your own Key Vault.
Both paths are first-class.
They differ in what they need and where your content goes. GeekIt is outside the path on both.
Claim A holds on both paths. Claim B is the one that changes.
The panel tells every user which path is in force before they send anything.
Which model answers?
On the Foundry path, it is the deployment your team points G-Code at. A deployment that speaks one of the supported APIs will function. How good its proposals are on a model GeekIt has not assessed is for you to judge. We don't claim that every model works.
What it does inside the work item
Your house style, under your review
Epic breakdowns you stay in charge of
Epic breakdowns you stay in charge of
Skills are files in a git repository your organisation controls: by default, an Azure Repos repository in your own organisation. A team lead writes "how we break an epic down here" once, and changes it by pull request and review. Every response names the skill that shaped it, and a merged change is in effect for everyone within fifteen minutes. A skill can narrow what the assistant proposes, never widen what the product may do.
Epic breakdowns you stay in charge of
Epic breakdowns you stay in charge of
Epic breakdowns you stay in charge of
The assistant proposes child work items for an epic or feature. You preview them, edit them and confirm before anything is created. They are created with parent links.
Field edits into the unsaved form
Epic breakdowns you stay in charge of
Source code context, only if your admin turns it on
Proposed edits land in the form you have open. Nothing saves itself.
Source code context, only if your admin turns it on
Source code context, only if your admin turns it on
Source code context, only if your admin turns it on
Off by default. When it is on, one repository and branch are chosen explicitly, the shipped default reads at most 15 files and 250 KB per request, files are read under the user's own permissions, and the exact file list is shown with the response.
Your identity, every time
Source code context, only if your admin turns it on
AI-written work is labelled
Every read and every write happens under the user's own Azure DevOps identity. No separate sign-in, no shared service account. The extension asks for two Azure DevOps scopes: Work items (read and write) and Code (read).
AI-written work is labelled
Source code context, only if your admin turns it on
AI-written work is labelled
Work items the assistant helped create are tagged ai-created or ai-assisted, so anyone can find them later.
What it looks like in Azure Boards
Who G-Code is for, and who it isn't for yet
A good fit when all of these are true
Not a fit (yet) if any of these is true
Not a fit (yet) if any of these is true
- You use Azure DevOps Services (dev.azure.com) with Azure Boards.
- You have an Azure subscription and someone who will own the component once it is installed: a platform team, a named IT owner, or a partner you contract to run it.
- You own inference capacity or can get it: a Microsoft Foundry deployment or an Anthropic account.
- Your security review cares whether a vendor sits in the data path.
Not a fit (yet) if any of these is true
Not a fit (yet) if any of these is true
Not a fit (yet) if any of these is true
You are on Azure DevOps Server (on-premises). G-Code supports Azure DevOps Services only.
Nobody would own it after it is installed. You run the component, and GeekIt cannot see it.
You need a vendor uptime commitment. GeekIt does not run the component, so there is none.
You want a hosted assistant with no infrastructure. There is no hosted version, and GeekIt does not operate G-Code for anyone.
Content must stay in your tenant, and you can't use Foundry.
You want the assistant to write without review, run in the background, or work across a whole backlog at once. It works on one work item at a time, and every write needs a person's approval.
Your process requires a named security accreditation held by the vendor. None is claimed.
What adoption involves
You operate a component, not just install one
Everything in this section is already on the G-Code listing on the Visual Studio Marketplace. It is collected here so you can read it in one place before you talk to us. Four things, stated plainly:
- You operate it. GeekIt can't. The proxy runs in your own Azure subscription. GeekIt has no credential, no role and no network path into your deployment, so GeekIt also can't see whether it is healthy.
- It is a single point of failure. If the proxy is down, the assistant is down for everyone in your organisation. An expired licence also stops it for everyone, and recovery is applying a replacement licence.
- It costs money to run, separately from the licence and from inference. At the shipped default (10 to 30 people in one Azure DevOps organisation, up to 10 concurrent and 200 daily requests), recurring Azure infrastructure is roughly $33–$90 a month: list price, UK South region, an order-of-magnitude estimate rather than a quote. Your region and Azure agreement will move it. Inference is a separate line on your own provider bill, and is likely to be the larger cost.
- The availability you get is the availability you build. GeekIt commits to no uptime figure, because GeekIt does not run it. The product ships a health and diagnostic surface for your own team.
What the licence covers, and what it doesn't
What the licence covers: the extension, the proxy container image, the infrastructure-as-code that deploys it, and the installation documentation.
What it doesn't cover: model inference, billed to your own Microsoft or Anthropic account; and the Azure resources the deployment creates, billed to your own subscription.
What the deployment keeps, all in your own tenant
Conversations are not kept. Attribution records (who, when, how long, token counts, and no content) go to your own Log Analytics workspace, kept for as long as you choose.
Support, platform and maturity
Support: by email. What to send us, and our acknowledgement targets, are on our support page: https://geekitmea.com/support
Platform: Azure DevOps Services only.
Maturity: an early product. The first generally available release shipped in September 2026.
Evaluation, and the full documentation
Evaluation: on request. The install runs entirely in your own tenant and is removed by deleting one resource group.
The detailed installation and security documentation ships with the product. Before you buy, we will walk your platform engineer and security reviewer through it in a technical briefing.
A technical briefing
For your platform engineer and security reviewer
A session of about an hour with a GeekIt engineer, for the people who have to say yes: your platform engineer, your security reviewer and your Azure DevOps administrator. It covers:
- The architecture, and the data flow on each inference path
- What self-hosting commits you to
- The prerequisites, at summary level
- The two Azure DevOps scopes, and why each is needed
- How offline licensing works
- A live network inspection on GeekIt's own internal deployment, using made-up content, showing that nothing calls GeekIt
Prefer it in writing? Email your security questionnaire to geekitsales@geekitmea.com and we will answer it in writing.
Found a security vulnerability? Please report it to security@geekitmea.com, not through this page.
How to get a price: one email
G-Code for DevOps is a paid product, licensed on a bring-your-own-licence basis. One licence covers every Azure DevOps organisation under the agreed tenants. GeekIt invoices you directly; nothing is billed through the Visual Studio Marketplace.
We don't publish the figure. We quote it directly, and the aim is a quote in one reply with no call needed. Tell us:
- Your organisation's legal name and invoicing country
- Which Microsoft Entra tenants the licence should cover, and how many
- When you would like to start
- Any procurement steps on your side: purchase order, supplier registration, contract review, security questionnaire
- Whether you would like to evaluate first
- Whether you would like GeekIt to guide your engineer through the install (a separate service, quoted separately)
The reply includes the figure, what it covers and what it doesn't, and the support terms.
Separate from the product: a guided install from GeekIt
GeekIt is also an Azure implementation partner. If your team hasn't deployed something like this before, we can guide your own engineer through the install.
How it works: your engineer does every step, in your own tenant, under your own accounts. A GeekIt engineer talks them through it on a call and watches a shared screen. We don't take remote control, and at no point are we given a credential, a role or any access to your environment. We never need to see your work item content.
It ends when the install is verified and handed to the person who will own it. From then on, your team, or a partner you contract, runs G-Code. GeekIt does not operate it for anyone.
It is a separate services engagement under its own agreement, quoted separately from the licence. You never need it to buy or run G-Code: the product ships everything your own platform team needs to install it alone.
Ask for a quote, a briefing or an evaluation
Support, security and privacy
This form goes to geekitsales@geekitmea.com. For product support, email support@geekitmea.com. To report a security vulnerability, email security@geekitmea.com.
Please don't send work item content, source code or credentials. We don't need them.
This form is part of the GeekIt website, and the website privacy policy covers it. It is separate from G-Code itself, which sends GeekIt nothing.
GeekIt
Links and contacts
G-Code for DevOps on the Visual Studio Marketplace: the full overview, the Pricing tab, the licence terms and the G-Code privacy policy.
https://marketplace.visualstudio.com/items?itemName=GeekIt.gcode-for-devops
Support: https://geekitmea.com/support
Pricing, licensing, quotes, technical briefings, evaluations and guided installs: geekitsales@geekitmea.com
Support, and privacy questions about G-Code: support@geekitmea.com
Security vulnerabilities: security@geekitmea.com
The GeekIt website privacy policy covers this website: https://geekitmea.com/privacy-policy
The G-Code privacy policy, on the Marketplace listing, covers the product.