From shadow IT to shared git: how teams can build internal tools together

The fastest way to build internal tools with AI is to let the people who need them build them, and the safest way is to keep every one of those tools in your company’s git. Most companies have the first half already happening, out of sight. This post is about the second half: how teams can turn a scatter of private AI experiments into shared, reviewed tools without slowing anyone down.

Everyone is already building alone

Look closely at any team that has ChatGPT or Claude and you will find small tools nobody asked IT for:

• An operations lead with a quoting calculator on a personal app-builder account.
• A recruiter with a candidate tracker exported from an AI chat into a spreadsheet macro.
• An analyst with a dashboard that lives on their laptop and nowhere else.

Each one is useful. Each one is also a small risk: it lives on one person’s account or machine, nobody else can fix it, nobody reviewed how it handles data, and it disappears when its author changes jobs. Two people in different departments are probably building the same thing.

Banning this does not work. People work around bans, and the company loses the upside. The goal is to keep the speed and add the things that make software safe to depend on: shared code, review and a clear path to production.

How to build internal tools with AI as a team

The pattern that works is the one engineering teams already use, with the AI doing the typing:

1. One home for code. Every tool, however small, is a repository in the company’s git server, in a shared group or organization.
2. One approved AI. People build with the AI provider the company already approved, so nobody needs a new vendor review.
3. Small, saved steps. Each change the AI makes is a commit, so anyone can see what changed and undo it.
4. Review before production. A person who owns production looks at the code before it becomes something others depend on.

The hard part has never been the pattern. It is that non-engineers cannot set up git, a framework and a dev server, and the AI coding assistants that could do it for them, like Claude Code and OpenAI Codex, run in a terminal. That is the gap Jig fills.

A workflow that works today

Here is how a team can build internal tools with Jig right now.

IT sets the rules once

IT deploys Jig with a machine-wide policy file: which AI assistants are allowed, which git hosts code may be pushed to, private repositories only, and which publish targets are available. The policy is enforced by Jig’s local service. See the page for IT for the details.

People build on their own computers

Someone describes the tool they need. Jig runs a short interview, writes a plan for them to approve and drives the company’s approved assistant to build it, with a live preview. The project is a normal folder and git repository on their computer, and every step is a checkpoint commit on a jig branch.

Projects go to company git

From the project’s settings, Jig creates a repository and pushes to it. It works with GitHub and GitHub Enterprise Server, GitLab, Bitbucket, Azure DevOps, Gitea and Forgejo, and with any other git server through the machine’s own git sign-in. It uses each person’s own access and never needs admin rights on the git server.

Teammates pick up where others left off

Because the project is a repository, a colleague can open the same app in Jig, read the history and keep going. Jig keeps project notes, decisions and a to-do list inside the repository, so the AI on the next person’s computer has the same context.

Choosing what goes to production

Not every tool needs to be production software. A personal calculator can stay personal. The point of shared git is that the company can choose, with the code in front of it:

• Keep it local. Useful to one person, no shared data. It stays in its repository, visible but unpromoted.
• Share it with the team. Published to the team’s own hosting, for example a company Netlify account, or as a Dockerfile for internal servers.
• Promote it. An engineer reviews it through the usual pull request, hardens it if needed and takes ownership.
• Retire it. Duplicates get merged, abandoned experiments get archived. Nothing vanishes with a laptop.

That is a much easier conversation than the alternative, where the first time IT sees a tool is when it is already business-critical and living on a personal account.

What comes next

Some of the pieces that make this smoother for larger teams are on the roadmap, not in the product yet:

• Company templates. Approved starting points with your design system, sign-in, data connections and hosting, so every tool starts from a reviewed base instead of a blank page.
• A shared library. Company skills, components and brand kits shared across the organization.
• An admin dashboard and single sign-on. Seats, versions in use and update channels per team, with SAML or OIDC.
• More hosting targets. Vercel, Cloudflare Pages, GitHub Pages and Azure Static Web Apps.

Where to start

Pick a team with a backlog of small tools and one engineer willing to review. Then:

1. Create a shared group in your git server for AI-built tools.
2. Install Jig for the team, with a policy that allows your approved AI and that git host.
3. Ask each person to build one tool and push it there.
4. Hold a short review: keep, share, promote or retire each one.

Individuals can try it first on their own; Jig for individuals covers that. For team plans, see pricing, and if you are still convincing IT, read why IT keeps saying no to AI app builders.