This is a really good idea.

Taking something that is basically a lonely depressing activity and putting a social aspect around it.

Well done.

I don't work at Open AI but I use Codex as I imagine most people there do to.

I actually use it from the web app not the cli. So far I've run over 100 codex sessions a great percentage of which I turned in to pull requests.

I kick off codex for 1 or more tasks and then review the code later. So they run in the background while I do other things. Occasionally I need to re-prompt if I don't like the results.

If I like the code I create a PR and test it locally. I would say 90% of my PR's are AI generated (with human in the loop).

Since using codex, I very rarely create hand written PR's.

Do you use any tools to help with the code review part?

I imagine they mean a remote KVM. So you remote into a PC sitting in a basement in someones house in the US. You then make all your outgoing internet from thta setup and your IP address would look legit.

I've never worked on a mono repo that has the whole organizations code in it.

What are the advantages vs having a mono repo per team?

* Tooling improvements benefit everyone. Maybe that's a faster compiler, an improved linter, code search, code review tools, bug database integration, a presubmit check that formats your docs - it doesn't matter, everyone has access to it. Otherwise you get different teams maintaining different things. In 8 years at Microsoft my team went through at least four CI/CD pipelines (OK, not really CD), most of which were different from what most other teams in Windows were doing to say nothing of Office - despite us all writing Win32 C++ stored in Source Depot (Perforce) and later Git.

* Much easier refactors. If everything is an API and you need to maintain five previous versions because teams X, Y, Z are on versions 12, 17, and 21 it is utter hell. With a unified monorepo you can just do the refactor on all callers.

* It builds a culture of sharing code and reuse. If you can search everyone's code and read everyone's code you can not only borrow ideas but easily consume shared helpers. This is much more difficult in polyrepo because of aforementioned versioning hell.

* A single source of truth. Server X is running at CL #123, Server Y at CL #145, but you can quickly understand what that means because it's all one source control and you don't have to compare different commit numbers - higher is newer, end of story.

> What are the advantages vs having a mono repo per team?

If you have two internal services you can change them simultaneously. This is really useful for debugging using git bisect as you always have a code that passes the CI.

I might write a detailed blog about this at some point.

One of the big advantages is visibility. You can be aware of what other people are doing because you can see it. They'll naturally come talk to you (or vice versa) if they discover issues or want to use it. It also makes it much easier to detect breakages/incompatibilities between changes, since the state of the "code universe" is effectively atomic.

Not sure if I get it. If you are using a product like Github Enterprise, you are already quite aware of what other people are doing. You have a lot of visibility, source-code search, etc. If you have a CICD that auto-creates issues you already can detect breakages, incompatibilities, etc.

State of the "code universe" being atomic seems like a single point of failure.

GitHub search is insanely bad and it cannot do things like navigating to definitions between repos in an org.

If you want code search and navigation over a closed subgraph of projects that build into an artifact - opengrok does the job reasonably well.

Imagine team A vendors into their repo team B's code and starts adding their own little patches.

Team B has no idea this is happening, as they only review code in repo B.

Soon enough team A stops updating their dependency, and now you have two completely different libraries doing the "same" thing.

Alternatively, team A simple pins their dependency to team B's repo at hash 12345, then just, never updates... How is team B going to catch bugs that their HEAD introduces on team A's repo?

This is already caught by multi-repo tooling like Github today. If you vendor in an outdated version with security vulnerabilities, issues are automatically raised on your repo. Team B doesn't need to do anything. It is Team-A's responsibility to adopt to latest changes.

Curious because I haven't seen this myself. Do you mean, GitHub detects outdated submodule references? Or, GitHub detects copy of code existing in another repo, and said code has had some patches upstream?

Github has dependabot https://docs.github.com/en/code-security/dependabot/dependab... which can also raises PR's, though your mileage may greatly vary here depending on your language.

You can also configure update of dependencies https://docs.github.com/en/code-security/dependabot/dependab...

These work with vendored dependencies too.

(In our org, we have our own custom Go tool that handles more sophisticated cases like analyzing our divergent forks and upstream commits and raising PR's not just for dependencies, but for features. Only works when upstream refactoring is moderate though)

Some context.

1. Some LLMs support function calling. That means they are given a list of tools with descriptions of those tools.

2. Rather than answering your question in one go, the LLM can say it wants to call a function.

3. Your client (developer tool etc) will call that function and pass the results to the LLM.

4. The LLM will continue and either complete the conversation or call more tools (functions)

5. MCP is gaining traction as a standard way of adding tools/functions to LLMs.

GitMCP

I haven't looked too deeply but I can guess.

1. Will have a bunch of API endpoints that the LLM can call to look at your code. probably stuff like, get_file, get_folder etc.

2. When you ask the LLM for example "Tell me how to add observability to the code", the LLM can make calls to get the code and start to look at it.

3. The LLM can keep on making calls to GitMCP until it has enough context to answer the question.

Hope this helps.

I’ve been wanting to write this somewhere and this seems as good a place as any to start.

Is it just me or is MCP a really bad idea?

We seem to have spent the last 10 years trying to make computing more secure and now people are using node & npx - tools with a less than flawless safety story - to install tools and make them available to a black box LLM that they trust to be non-harmful. On what basis, even about accidental harm I am not sure.

I am not sure if horrified is the right word.

It may reduce consumerism in the US and therefore be beneficial to the environment.

Tesla in Berlin employs 12,000 workers and can produce 5000 cars a week.

The US will need a lot of factories to employ 10s of millions of workers.I also imagine new factories will employ less workers due to increased automation.

I'm interested to see how this plays out.

This isn't the 1950s, factories are mostly automated: https://www.youtube.com/watch?v=blW-Fa4a10g

That's the whole reason we went all in with tech and automation

In your scenario white collar jobs will be destroyed globally.

So effectively you would be paying people to work in manufacturing even though it's no longer necessary.

You may as well pay a basic income instead.

You need to take a Defence in depth strategy.

There are various ways to validate libraries but it's best to assume an exploit gets through.

So then, you should be looking at your deployment, i.e. locking down containers, network policies, least privileges etc etc.

Try to reduce the blast radius to zero.

It's very easy to install and add models.