Zero AI Engineering OS for Local Development

I was asked a few times "Can I use 𝗚𝗶𝘁𝗛𝘂𝗯 𝗖𝗼𝗽𝗶𝗹𝗼𝘁 like 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲"? My answer is: OF COURSE ! Just like Claude Code, GitHub Copilot(GHCP) can work in a "terminal like" mode (using GHCP CLI): It can plan workflows, Invoke tools automatically, read files, call APIs, query DBs, execute commands - all WITHOUT building the orchestration logic yourself. So what advantages does 𝗚𝗶𝘁𝗛𝘂𝗯 𝗖𝗼𝗽𝗶𝗹𝗼𝘁(GHCP) have over 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲? ✅ GHCP supports all the leading models (Claude, OpenAI, Gemini) including automatic model routing option, while Claude Code supports only Claude models. ✅ GHCP has native DevOps integration - especially if you use GitHub (it is GitHub workflow aware). ✅ In addition to the "Terminal mode" like Claude Code, it can work inside all popular IDEs: Microsoft IDEs (VSCode, VS), JetBrains IDEs, Eclipse, Xcode, Vim/Neovim. ✅ Enterprise Governance & Security - unlike Claude Code, you can define who can access GitHub Copilot, which features are enabled, what models are permitted, how policies are enforced across orgs and more. ✅ Comes with enterprise cost control & usage monitoring Bottom line: If you are an independent vibe coder - 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲 is a good choice. If you are a vibe-coder in an organization or a professional developer who also wants to vibe-code and needs an enterprise-grade tool - 𝗚𝗶𝘁𝗛𝘂𝗯 𝗖𝗼𝗽𝗶𝗹𝗼𝘁 is the right tool for you. #GitHub #GHCopilot #GHCP #MicrosoftAI #ClaudeCode

I have been working on both extensively and here’s my perspective. #GitHubCopilot is the accelerator. When the path is clear, Copilot keeps you in flow with fast inline completions, strong pattern recognition and seamless IDE integration. It’s perfect for features, tests and predictable day‑to‑day coding. #ClaudeCode is the problem‑solver. It thrives in ambiguity — reading large repos, reasoning across files, debugging complex systems and planning multi‑step changes. It’s built for refactors, migrations and architecture-level thinking.

Will add: it works out of the box to create dataverse columns off a simple json schema. Whenever I need a new table I generate a json schema create the base table connect to the MCP server and have copilot create all the fields.

After hours of frenetic building, it's finally at a point where i can talk about it. The problem: your team is scattered across Jira, Slack, and GitHub, and switching between them 24/7 is absolutely draining. plus half the time you're asking the same questions over and over again like "what's the status on this issue?" or "who was talking about this in the channel?" The solution: Built platform that just gets it. it's got three agents working rn: Jira Agent  - MCP integration + JQL fallback for when things get tricky. hit it with natural language, it generates JQL, fetches data, summarizes everything. never loses context Slack Agent - Uses MCP for seamless integrations. understands your channel convos, pulls insights without you having to scroll for 20 mins GitHub Agent  - MCP-enabled for smooth repo interactions. ask anything about your repo , it just knows what's next: this is literally just phase 1. the real magic happens when these agents stop being lone wolves and start sharing context with each other and start working together autonomously, actually smart collab > current standalone setup. if you're tired of context-switching, check it out :- https://lnkd.in/gnW_JKxs

I recently switched to using jj for a VCS and because I only think about Terraform state, it immediately made me think git vs jj is like Terraform vs Stategraph. In jj, so many things about git that were stressful (will doing this rebase put me in a state where I'm better off deleting the repo and cloning again?) into non-events. Do something wrong? No problem, "jj undo". I think there is an analogy here to what we are doing with Stategraph. The current Terraform world is like git, too low-level, too much concern about state. I want use to be like jj, state is a non-issue. On example is our "refactor" feature. It's common to see on /r/terraform people asking about how to safely go about a refactor and genuinely be concerned about messing it up. With Stategraph refactor, you can safely let Claude go brr on a nasty repo and move things around to make it nice, and Stategraph figures out if it's safe. We've already refactored a bunch of gross repos. As a community, I think we have to do better here, it shouldn't just be us, at Stategraph, trying to solve the hard problems instead of trying to hide it under some automation.

Well, it's live! https://biomelab.dev/ I've building this project to make my workday more prolific. If you are into #agentic development workflows, using git worktrees for parallel task, you probably want to take a look at this project, which helps me in monitoring the ongoing work. Spoiler alert: it uses Docker, Inc Coding Agent #Sandboxes under the hood for adding safety to your workflows 😉

I open-sourced aidock: a single script that runs AI coding agents inside a container. Copilot CLI, Claude Code, and Codex all get full filesystem access when you run them locally. That means one bad tool call can touch files it shouldn't, read your SSH keys, or wipe your home directory. Sandboxing is the obvious fix, but wiring up user namespaces, auth forwarding, and toolchains is tedious. aidock is a self-extracting Bash script that builds a Fedora container with 9 language servers, 4 MCP servers, and three AI agents pre-configured. One command to launch. Your project is mounted read-write; everything else stays out of reach. It works with Podman or Docker, seeds editable config on first run, and the entire environment is defined in a single Containerfile you control. github.com/ruifm/aidock

Interesting take on the effect of AI driven software development on repositories, and GitHub more specifically— it seems that the added workload stemming from a huge increase in push and pull requests is pushing the infrastructure beyond its limits, resulting in much more frequent downtime.

How I Leaked Secrets Publicly === I love Claude, we code every day in a private github repo with .gitignored ./SECRETS dir for devops a merge conflict in .gitignore? Claude resolved, SECRETS unignored next day: git add -A, git commit; git push wow, our SECRETS were just pushed to git?! how? ok, clean up, rotate. it's in a private repo, what could ever go wrong? weeks later, a brilliant idea - let's publish our CLI open source! CLI is in a monorepo. How do we make it standalone? Ask user: A) copy into new repo - but you need to manage 2 repos from now on B) keep in monorepo, and use git subtree sync in actions Go B. All clean, nothing is going to leak? Sure? Yes? Go! Published! CLI is out. First email came like 5 min later. Then 10 more very soon. - Paddle API key secret leaked. - Anthropic secret leaked. - Firebase secrets leaked. - Gemini, Deepgram, etc. (the majority of keys were rotated and inactive, but are we 100% sure?) Robots scan public repos for leaks. Not just a clean main branch. The full history. Good actors let you know what you messed up. Bad actors? I would never know. Claude would never know. Claude - panic mode. Ok, delete repo, start over. A few hours later - nice, we rotated all the secrets again. Up & running again. What a productive Monday. My bad. Sharing so you learn from my mistakes, not yours.