Video Summary - I don't have time to build these things, will you?

Core message

Choose problems that actually exist, and use agents—but don’t ignore what you build.
Software architecture details matter less than selecting the right problems/projects.
Start from a real pain point (personal or production), then iterate (“rabbit hole”) until something useful emerges.
Agents can make more projects viable, but not every project at once.

Idea list for developers

The video frames multiple “build bigger” product/platform ideas, emphasizing security, developer experience, and agent safety.

1) Better NPM / Better NPX (distribution + security + metadata)

Problems with today’s NPM

Security: NPM is a frequent attack target; updates/exploit mitigation can make it harder for good-faith developers.
Publishing difficulty: uploading releases is painful and mistake-prone.
Irreversibility: incorrect version numbers can’t be removed/revoked easily.
Ecosystem fragility: even major maintainers can cause dependency/version issues that are hard to undo
- Example referenced: TanStack Query / React Query version confusion.

Proposed features for a new NPM platform

Release revocation thresholds
- Revoke if installed fewer than a threshold number of times (e.g., < 100)
- Or if the release has existed for a short time window (e.g., < 5 hours)
Audited releases
- Maintainters can pay for automated security audits
- Example workflow: an “auditor” (speaker mentions Anthropic conceptually) compares diffs and returns a “safety/intention vibe check”
More visibility/metadata about packages
- Readability (obfuscated vs de-obfuscated)
- Whether it’s readable JavaScript
- Open-source status
- Who published the last release
- Trust/backing by known people
Kill name squatting
- Encourage agents/people to vet and reassign requested package names that are already taken/squatted
- The claim: squatting leads to extortion; open-source platforms should make it hard-banned

Better NPX: safer, more informative “executable packages”

Current NPX prompts are described as “insultingly unhelpful” because they require permission to install but provide little actionable info.

The speaker wants NPX to show:

App size/impact estimate
Author info and recency of changes
A safety/likelihood score
The permissions the command will run with

Agent safety concern

If an agent is configured to run NPX commands (e.g., via a skill.md), a malicious takeover of an NPX package could cause silent execution.

Proposed mitigation:

Agents/users should receive a heads-up and risk scoring before running.

Auditing subscription for small OSS tools

Even low-cost auditing (they mention “50 cents”-level pricing) for a verified third-party review is framed as valuable.

Private registries / environment-specific packages

Desire: NPX defaults to private registries for packages in a user’s environment.
Example: each developer has their own registry/bucket for customized packages without publishing publicly.

Why rebuilding NPM is “timely” (claimed)

Packaging/distribution infrastructure is expensive, but the speaker argues costs dropped due to new tooling/agent capabilities.
Mentions Socket using AI to find NPM exploits before or faster than NPM maintainers.

2) “Reinvent source control from scratch” (permissions + secrecy + better primitives)

Main complaint: Git/GitHub primitives don’t support modern needs

The speaker argues Git is an outdated abstraction:

Git assumes repo-wide visibility/permissions instead of content/change-level permissions.
It lacks granular secrecy controls (e.g., private branches, private files, private PR visibility, delayed public merge visibility).

Security urgency:

In a security crisis, delaying disclosure can prevent “zero day” exploitation.

“Commit/env file” example

They ask why .env files (or secrets) can’t be committed safely with access control.

Claim:

Current workflows require external secret-management because Git provides no mechanism for it.

Limitations they want fixed

Commits/branches are described as ergonomically and conceptually wrong for modern collaboration.
Work trees are called “atrocious” (example: one worktree checks out main, blocking other operations).
Alternatives suggested (influenced by JJ):
- Use snapshots/tags instead of commits/branches to reduce wasted attention on history

“No real OS/file system needed”

They criticize Git’s reliance on a real file-system + CLI workflow.

Proposal:

Run SCM-like operations inside virtualized environments (example: “just bash” / JS/TS emulation).
Agents could operate in memory without heavy OS-level file operations.

Performance rant: APFS small-file performance

They cite benchmarks (clone + pnpm install recreation/cached install) showing extremely slow small-file creation on macOS/APFS vs Linux.
They argue this harms agent workflows that spawn many isolated environments.
Speculation: causes include fsync and platform-specific filesystem syncing.
Conclusion: in-memory/non-filesystem approaches avoid platform inconsistencies.

“Dropbox for devs” (syncing dev directory structure across machines)

A “dream system”:

Consistent directory structure across machines (Mac mini, NAS, Ubuntu box, etc.)
Pull-on-demand of subfolders/files when an agent touches them
Sync environment variables and code layout reliably

They argue existing solutions don’t fully solve:

Worktree staleness across machines
Missing env vars per machine
Knowing where projects live

They mention starting a project concept “FS2”, but it didn’t go far enough.

Framing:

This is positioned as an agent + synced workspace problem, not just a Git/submodule problem.

3) Rethink mobile app platforms (Apple/Android constraints + openness)

Critiques of current platforms

iOS/App Store: digital goods/payment constraints and arbitrary bans.
Android distribution: opaque rejections.
iOS dev metadata issues: permissions tied to source control configuration.
Overall: mobile dev is described as too hard compared to customizing a platform OS.

CyanogenMod era as inspiration

CyanogenMod is presented as proof that customizing/forking Android could be easier than building apps.
The key advantage: “flash a new OS” made experimentation accessible.

Paranoid Android + Paul Henschel (0xCA0A)

A key open-source mobile platform creator is linked to earlier ROM hacking.
Claim: Paul built Paranoid Android because app-building “sucked” at the time.

BlackBerry 10 as ecosystem-compatibility example

BlackBerry 10 reportedly supported Android apps via an internal Android runtime/virtualization.
Used to argue new OSes can still support existing app ecosystems.

Proposed future: “NPM for mobile” via OS-level openness

They imagine a mobile OS where:

Apps and customization are easier
Developers build new experiences quickly
Users can install/demos via a QR-code flow
Just-in-time compilation is allowed

Concern:

The feared “duopoly” (Apple + limited/slow change on Android) blocks this future.

4) Slack is the wrong abstraction for agent-centric work; need “posts + context”

Why Slack doesn’t fit agent-centric workflows

Slack is criticized as being designed for sending messages, not:

reading
prioritizing
status management
maintaining context over time

Specific complaints:

Inline replies are missing (threads are required)
Thread history/visibility is poor
Thread replies aren’t discoverable when activity is old
Code block/UX concerns mentioned but not detailed

What they want:

Infinite/nested threads that preserve context
Better agent integration with a shared “control plane”
Chat primitives that behave like persistent posts, not ephemeral messages

Facebook Workplace as the closest fit (but shut down)

They praise Workplace-style:

“post + nested comment replies”
old posts resurface when new comments arrive

They claim Workplace was shut down for development (announced end; they reference “two weeks ago” and “August of last year”).

Proposed direction: replace Slack slowly with an open standard

They imagine:

a Slack-like system built around posts/comments
adoption as an open-source standard

Concept mentioned:

Hermes Agent (as an example idea): agents post to content items that bump those items back to the top

Note:

They suggest Microsoft Teams may have similar ideas, but won’t be useful due to Microsoft’s nature (as stated).

5) Need more benchmarks for AI models + agent capabilities

They call for:

more benchmarks, including “weird benchmarks”
benchmarks written by non-lab developers
reproducible versions of failed tasks

Examples they want:

agent benchmarks for developer workflows like Git
- They mention a Git benchmark by “CM Griffin”
visual tasks (e.g., sky image recognition)
medical diagnosis from screenshot-like scans
agent performance on obscure programming languages

Argument:

Benchmarks can incentivize labs to improve—e.g., a benchmark showing where agents fail could drive fixes.

Main speakers and sources mentioned

Main speaker: the creator delivering the ideas (not named in subtitles)
Sponsor: CodeRabbit (PR “review change stack”)

Systems/products referenced

NPM / NPX
Socket (AI audits for NPM exploits)
Git / GitHub
JJ
Just/bash (JS/TS “bash” emulation)
Dropbox (for “dev sync” concept)
CyanogenMod
Paranoid Android (Paul Henschel / 0xCA0A)
BlackBerry 10
Slack
Facebook Workplace
Microsoft Teams
Hermes Agent (mentioned conceptually)
Benchmarks / SkateBench (speaker’s example benchmark)
CM Griffin (Git benchmark mentioned)
Theo / Robert (chat participants referenced)

I don't have time to build these things, will you?

Key takeaways