Rebuilding NPM, Git and Slack is worth attempting now because the expensive part of software used to be writing it, and that part got cheaper. Six ideas from Theo's video, each with a named failure and a named fix.
Rebuilding NPM, Git and Slack starts with one shared diagnosis
Every platform on this list was designed around assumptions that no longer hold, and each fix has only recently become cheap enough to attempt. That is the whole argument. The list comes from a developer who has kept it for years and wants someone else to build from it. He frames the shift plainly: how we build matters less than it used to, and what we build matters more.
The six ideas are not equal in ambition. Two of them mean replacing a core developer tool, one means replacing your file system, one means writing a new mobile operating system, one means replacing the chat app your company already pays for, and one is a weekend project.
Source: I don't have time to build these things, will you? on Theo - t3.gg.
Why is rebuilding NPM the most urgent idea on the list?
NPM is both an incredible piece of software and a platform under daily attack, and the same security pressure that makes it a target makes it harder for honest developers to use it. Publishing is the second half of the problem: once a version is out, it is out permanently.
The TanStack Query mistake is the clearest example. A typo in a version number shipped, and React Query's latest release is still not the version it was supposed to be, because NPM does not allow the publication to be revoked. The reason is historical: NPM refuses to let packages vanish in case an old app needs to rebuild its dependency tree years later.
That policy protects builds and traps maintainers. The fixes below keep both goals.
What a better NPM would ship
- Revoke releases at a threshold. If a package has been installed under 100 times, or has been up for under 5 hours, revoking should be allowed.
- Paid audit of every release. Hand over a credit card number and an API key, and have a model diff each release and score whether it looks safe or intended.
- More metadata per package. Is it obfuscated or de-obfuscated? Readable JavaScript or not? Open source or not? Who published the last release? Backup: people we know?
- Kill name squatting. Verify claims on existing names with a person or a set of agents that vet well enough to hand the name over.
- Private registries as a default. Publish to your own registry and make it the default source over the public one, so you and I can each have our own TanStack package tuned to our needs.
The name-squatting problem is not theoretical. The TanStack package on NPM is not owned by Tanner. It was taken by a squatter who tried to sell it back for a large sum; when Tanner refused, it was sold to a company called 30 tools. The typing risk is just as concrete: a package named is-odd with a zero instead of an O can read your file system and call your network, and the install screen looks identical to the real one.
Socket is already proving that automated audits work. The company uses AI to audit new releases and finds exploits before NPM does, which means the signal a rebuilt registry would surface is not speculative.
Why NPX might be the more interesting entry point
NPX is the executable layer of NPM, and today it asks you a question it gives you no information to answer. Run an unfamiliar package and you get a version number and a yes/no prompt. That is the whole interface.
Imagine the same prompt showing the install size, the author who most recently changed something, a safety score, and the permissions the code requests when it runs. That matters twice over now. An agent following a skill file can run an NPX command unknowingly after someone takes over the package, and your agent would have no way to flag it. Give the agent the metadata and it can stop and ask you instead.
A paid audit of 50 cents per small open-source script, run by a verified third party so the results cannot be faked locally, would make people want to use NPX far more than they do now.
This is not a small build. It means integrations for publishing, a registry, a CDN for the code, a verification platform, and CLIs. The speaker's argument is that this is now affordable, where before it was neither affordable nor likely to win users.
Why is Git the wrong abstraction for how teams work today?
Git beat everything that came before it and became the standard for good reason, but it was built for the Linux kernel, and the assumption baked into it is that the repository holds the permissions, not the contents of the repository. That single assumption now costs teams a great deal.
Start with the question that sounds silly: why can't you commit a .env file? Because everyone with repo access would get your secrets, and once a secret is in the repo it is there forever. Open source later and the values are public. Hire and fire someone and they keep the file. Hand the project to another team that does not need the environment variables and they have them anyway. The whole industry of secrets-management companies exists to work around a file that ends up as a random file on your computer regardless.
Git offers no granular permissioning at all. No private files in a repo. No private branches. No pull requests that stay private until they merge. No delay on when a merge becomes visible to the team. Recent work from DeltaDB at Zed and Cursor's Origin gesture at the problem, but mostly by adding agent context or making clones faster for parallel agents, not by fixing the primitive.
What Git could not do, and what it costs
The security case is the sharpest one. When a critical fix lands in the Linux kernel, agents watch every patch and look for the security fix, which hands attackers zero-days before the fix is announced. A source control system that could merge a fix, cut a release, and distribute it to the maintainers of vulnerable distributions before the code went public would change that race entirely.
The project-shape case is more common. Claude Code would be a likelier open-source candidate if work in progress did not have to be public the whole time, because roughly half of it never ships and observers would have held the abandoned attempts against it. Monorepos with a few private sub-packages would remove the need to split a project into several repos purely to control what gets shared. In all of these cases you shape your work around what you are allowed to reveal, instead of using the tool to shape what is revealed.
Smaller grievances add up. Commits are a reasonable unit but a poor fit for how agents work; branches are worse. Jujutsu (jj) replaces branches and commits with snapshots and tags and solves enough of the ergonomics that going back feels like a downgrade. Work trees are worse still: in the transcript, an agent's work tree checked out main, which blocked checking out main in the actual main directory.
Does source control need a real file system?
No, and the numbers make the case. Novox Populi shared a disk benchmark that measured cloning a project full of boilerplate sub-frameworks and running a PNPM install from cache with no network involved, purely to see how long recreating the files takes.
| Platform | CPU and disk | Clean install time |
|---|---|---|
| Ubuntu | mid-range AMD CPU, Western Digital SSD | 6.8 seconds |
| macOS | M4, Apple SSD | 31 seconds |
| macOS | M1 Ultra | up to 140 seconds |
| macOS | same MacBook running Ubuntu | 3 to 12 seconds |
The gap points at APFS, Apple's file system, which handles many small file writes badly. That matters directly for agents, because spinning up lots of small working environments is the whole workflow. It also explains why RAM disks and other file-system workarounds start to look reasonable. The details are apparently in how Fsync behaves; the speaker is not interested in which layer is at fault, only that cloning and installing on a Linux machine feels dramatically better than on a Mac.
just-bash offers the other direction. It emulates bash in a JavaScript or TypeScript layer so an agent can run without a real Linux kernel or a real file system, entirely in memory. Cloning and rearranging directories in memory is far easier than moving files around on disk.
Why do we need Dropbox for dev machines?
Because your code folder is spread across several machines and nothing keeps it consistent. The transcript's setup is a Mac Mini in one room, another Mac Mini downstairs handling home automation, a GMK Tech Box arriving the same day to run Ubuntu with more RAM, and cloud agents on top of all of it.
The failures are mundane and constant. A work tree was spun up without pulling the latest main, so a build ran on a stale base. An environment variable existed on one machine and not another. A project was in a different directory on a different machine because the folder layout was never identical to begin with. The comparison is Dropbox: one folder structure that exists identically on a NAS, on an editor's machine, and on a laptop, with the same contents in all of them.
Git does not solve this. Managing multiple repos without nesting a Git repo inside another means submodules, and nobody wants submodules.
What the idea asks for: your code folder looks the same on every machine with no effort, environment variables sync, and node modules are handled per-OS. The stronger version is lazy materialization. The structure of every project is present immediately; the actual files download the moment an agent or a person touches them. The speaker started a project called FS2 (file system two) and concluded it would not go far enough, which is why this idea replaced the file-system idea he nearly included instead.
One viewer in chat, Robert, said he had been dreaming of exactly this but did not have the skills to build it. The answer applies to every idea here: what it takes is a token budget and patience, not prior knowledge.
Why is this the last chance to build a new mobile platform?
The mobile duopoly has no incentive to change. Apple takes a 30% cut on digital goods and requires them to run through its payment systems, which is why you can buy an Uber ride with a credit card but not a game. Apple also bans releases it dislikes, so the newest Xbox game is not on the App Store and requires a $100-a-year developer account plus hours of manual setup. One detail captures the developer experience: Info.plist has to contain the developer and team, which hardcodes one person's config into source control.
Android is easier to start building on and worse to ship on. Google rejects releases without enough information to fix the rejection, while Apple at least gives you a bad reason. The transcript's example of how bad it gets is a team member asking for the speaker's home address to file paperwork so they could resume building the app.
The CyanogenMod era, and what it got right
Custom Android ROMs once made modifying the OS easier than shipping an app, which is the inverse of how it should be. CyanogenMod shipped vanilla Android with useful additions: overclocking, status bar color changes, bloatware removal, custom kernels, and better performance. Around 20 flavors of custom ROM existed at the peak, built by independent developers for fun. The speaker was deeply involved.
The claim to sit with is that the barrier to building an app was higher than the barrier to forking the OS. Put in browser terms: editing your browser was easier than putting up a website.
Paranoid Android, one of those ROMs, was founded by Paul Henschel, also known as 0xCA0A, who went on to create Zustand, Poimandres, and React Three Fiber. A developer who built an operating system before he built packages became one of the best-known React community developers instead. The speaker's spicy take is that Paul would have become a mobile developer if mobile development did not make it so hard, and Android lost him because forking the platform was easier than building on it.
What BlackBerry 10 proved
BlackBerry 10 ran a complete Android runtime, so a phone with its own proprietary OS could run Android apps. That solved the ecosystem problem that has killed every new mobile OS: you keep the apps you need while the platform itself is different. It did not sell, for reasons that were not technical. Android apps ran a bit worse on the available CPUs, virtualization cost more than it would today, BlackBerry's software was closed source and device-only, and there was no reason to choose it over an Android phone.
So the proof of concept exists. What is missing is a platform that supports Android apps while encouraging people to build on it. The shape of the ask is: fork and modify apps, allow just-in-time compilation, and let someone scan a QR code to get a demo onto your device. Something like NPM, but for mobile. The speaker is not optimistic about the schedule, noting that the best route to shipping a good Android idea used to be leaking it to Apple first, and that Android improving is near zero probability while Google invests so little in it. Open bootloaders still ship on enough devices to make the attempt possible.
Why does Slack feel miserable, and what would replace it?
Slack is built for sending messages, not for reading them. It has no real inline replies, so every reply becomes a thread. Threads fall back in the history even while they are active, which makes them hard to find, and you cannot reply to a single message inside a thread without quoting it manually. Code blocks are another sore point.
Agents exposed how deep the problem goes. Forcing agents into Slack only demonstrated that Slack is not built to prioritize work, surface status, or route context. It has no answer for a sub-comment that should be handed to an agent to explore and report back.
Slack's real moat is shared channels between companies, which is why almost every channel in the transcript exists to talk to another company. That is a lock-in mechanism, not a feature advantage.
Facebook's post primitive was the right shape
Facebook Workplace is the closest thing the speaker has seen to good context management for a team. A post can live on a wall, in a group, or on someone else's wall. Top-level comments respond to the post; comments nest; replies nest inside comments, so two people with different takes can each get a direct answer without clogging the main thread. Most importantly, a comment on an old post bumps that post to the top. Nothing else does that.
The argument is that posts sit between a channel and a thread, which makes them a better base unit than a message, with threads as the sub-unit underneath. That structure suits agents as well as people.
Workplace shut down two weeks before the video was recorded, and development had already been announced as ending in August of the previous year. The one product that could have done this stopped iterating. The speaker started building his own version and ran out of time.
Combining a post-based workspace with something like Hermes Agent is the picture: instead of unmanageable threads spun up in Discord (still better than doing it in Telegram), you have a content system where posting a task and having an agent reply bumps the thread back to the top. Microsoft Teams has some of these ideas somewhere, but it is Microsoft Teams. The goal is an open-source standard that slowly replaces Slack rather than one that tries to replace it at once.
Why do we need stranger benchmarks?
Benchmarks built by people outside labs measure things labs do not think to measure, and once a weakness is measurable, the labs compete to fix it. That is the entire argument for weird benchmarks.
The speaker's own SkateBench measures how well models name a skateboard trick from a description. It sits between a complex grammar benchmark, a niche English-language benchmark, and 3D spatial reasoning, and researchers have asked about it because the numbers are interesting on their own. CM Griffin built Git Bench to measure how well agents handle Git. The wider list runs from reading aerial photos to identifying cancer in MRI screenshots.
The practical advice is to save the work you tried to hand to an agent and that failed, in a reproducible form, so it can be tried again. If you use an obscure language like Crystal and the models are bad at it, a benchmark showing the gap is the fastest way to get the labs to care. A benchmark that proves every agent fails at a task is the strongest possible incentive to fix it.
What are the six ideas in one place?
| Idea | The failure it fixes | The fix in one line |
|---|---|---|
| Better NPM and NPX | Publishing is irreversible and installs show no risk | Threshold revokes, paid release audits, richer metadata, private registries |
| New source control | Repository-level permissions, no private files or branches | Change-level visibility, private merges, memory-native source control |
| Dropbox for devs | Your code folder differs across every machine | One synced structure with lazy file materialization |
| New mobile platform | Apple's 30% cut, opaque bans, Android neglect | An OS that runs Android apps and invites building on it |
| Slack replacement | Messages, not posts; no useful nesting | Post-based workspace with bumping, agent-ready |
| Weird benchmarks | Labs ignore what nobody measures | Publish reproducible benchmarks for what agents fail at |
One standing caveat from the transcript: if you build one of these, the speaker's own adoption is unlikely at first. If he sees other people using it, including his own team, he will take a look.
FAQ
- What is the single shared problem behind all six ideas? Each platform was designed around assumptions that stopped being true, and the fixes only became affordable recently. The speaker's framing is that how we build matters less now, so what we build matters more.
- Why can't an npm package be unpublished? NPM keeps every published version so old projects can still rebuild their dependency trees. That is why the typo'd TanStack Query release cannot be revoked, and why a threshold-based revoke (under 100 installs, or under 5 hours old) is the proposed middle ground.
- What is the difference between NPM and NPX in this context? NPM is the package platform; NPX is the executable layer that runs a package without a permanent install. The speaker argues NPX is the more interesting thing to rethink, because it currently shows no safety information at all.
- What does the disk benchmark actually measure? Cloning a project full of boilerplate and running a cached PNPM install, with no network involved, to time how long file creation takes. Ubuntu on a mid-range AMD CPU with a Western Digital SSD finished in 6.8 seconds; an M4 Mac with an Apple SSD took 31 seconds for the same work.
- What is the strongest precedent for a new mobile OS? BlackBerry 10 shipped a full Android runtime, which is exactly the pattern a new platform would need to keep the app ecosystem. It failed commercially for performance, ecosystem and closed-source reasons rather than for the concept.
A closing note on building bigger
The thread running through all six ideas is the same one the speaker states at the start: pick a problem you actually have, solve it, and let the next problem appear. Every item on this list started as a real annoyance, then turned into a project someone could build.
If you have that kind of material sitting in a YouTube video, an explanation, an interview, or a long rant about a problem nobody has fixed, it can become a written article. Paste the video URL into Skalablog, let it transcribe the video, and generate the article from the transcript.
For a full stack of the tools that show up in this kind of development work, see CrazyStack Typescript.
Gustavo Dev Doido publishes developer content in Portuguese, and the same ideas from this article show up regularly in those discussions about developer tooling and platform design.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits