Theo’s Six Ideas for Better Developer Tools and Platforms

I spend a lot of time thinking about how we build software, but what we build still matters. Choosing the wrong project can feel like a waste, so I usually suggest starting with a problem you actually have. Solving it reveals more problems, and following that trail can produce something useful.

Ideas feel more important now, and I know many developers are unsure what to work on. I have kept a list of things I wish existed. Agents make any one of these projects more feasible for me, but I still don't have time for all of them, so I'm sharing the list.

First: a better npm, including npx. npm is an incredible piece of software, but its size makes it a security target, and new defenses can make legitimate publishing harder. For me, publishing packages has increasingly become one of the hardest parts of a project.

An accidental version publication can be difficult to undo; npm's concern is that removing a dependency might break a future rebuild. Changing that behavior has real ecosystem risks, but I would like a limited revocation window—for example, a release with fewer than 100 installs or less than five hours online.

I'd also like optional paid auditing of release diffs, and more visible metadata: whether code is readable or obfuscated, whether it is open source, and who published the latest version. That information should appear both on the registry and when installing from the CLI.

A lookalike package can perform suspicious filesystem or network operations without the install experience making its risk obvious. Different packages have different needs and risks, and users should be able to see those differences. I also want a better process for resolving package-name squatting.

npx is an especially interesting entry point because it can distribute small executable tools, including tools agents need. Today, an installation prompt may give me a version number and a yes-or-no question without enough information to judge the code. I'd like to see the author, size, permissions and an indication of risk.

This matters for agents too: a command in a skill can run a package that has since been compromised. An agent could surface an alert and ask the user what to do. I imagine independent automated audits producing a rough risk indication, not a guarantee that a package is safe.

Private registries would let people share their own small tools without publishing everything publicly, with a private package taking precedence where appropriate. Building a replacement involves publishing integrations, hosting, a CDN, verification, registries and CLIs. That's a lot, but AI has changed the economics enough that I think it's worth trying.

Socket is an example of work on auditing releases; there is room to build better tools on top of npm or alternatives to it. My second idea is even more ambitious: rethink source control. Git became the standard for good reasons, but its assumptions don't match every current need.

Take environment files. Putting secrets in a repository exposes them to people with repository access and can leave them in history. Separate secret-management services help, but I want to ask why source control itself can't support private files, private branches or pull requests, and finer-grained access.

Security fixes provide another example. I want maintainers to be able to prepare and distribute a fix to affected parties before publishing the code, reducing the window in which attackers can inspect a patch before users update. That raises a genuine tradeoff about openness; I think security deserves more weight here.

In a post about this, I also asked whether unfinished pull requests could remain private and whether a monorepo could contain private subpackages. I've split projects into multiple repositories because I could share only part of the code. I'd rather the tools let me shape what is shared than force the project structure to follow that constraint.

Commits and branches are another place to reconsider the model. I like the ergonomics of Jujutsu, even though it doesn't solve my biggest concerns; its approach to snapshots and tags made me question how much time we spend managing history. Git worktrees also frustrate me, such as when one worktree prevents another from checking out the same branch.

I also wonder whether source control needs to depend on a real operating system and filesystem at all. Tools such as just-bash can emulate a shell in JavaScript, allowing an agent environment to operate in memory. Copying environments there could avoid some of the cost of moving large numbers of files around.

A disk benchmark shared by NullVoxPopuli helped explain my frustration. It clones projects and installs cached dependencies, measuring file creation rather than network downloads. In the results I saw, an Ubuntu system took 6.8 seconds while an M4 Mac took 31 seconds; other Mac results were much slower. This is a particular workload, not a universal filesystem comparison.

I don't know whether fsync is the cause, as some have suggested, but the experience makes me want alternatives to filesystem-heavy workflows. In-memory representations could avoid some platform-specific behavior, even if real systems still need to handle persistence and other practical details.

My next idea is Dropbox for developers. I work across several machines and keep encountering stale worktree bases, missing environment variables and differently organized project directories. Dropbox gives my other work a consistent folder structure across machines; I want something comparably convenient for code.

Imagine starting a machine and finding your whole code directory in the same structure. Environment configuration would be available too, though platform-specific dependencies such as node_modules need special handling. Managing a collection of repositories through another repository and submodules is not a satisfying substitute for me.

I started a project called FS2, but my ideal would go further: preserve the directory structure everywhere and fetch portions lazily as a person or cloud agent accesses them. It should work with existing tools and automatically include new projects, with an ignore mechanism like .gitignore for sync.

A viewer said they'd dreamed of this but lacked the skills. My challenge is to test that assumption: today's models and agents may help you get further than you expect if you have the patience and resources to work through the hard parts. I hope several people try.

Then there's a new mobile platform. I used to be an Android enthusiast, and now I rely on an iPhone, but I find mobile distribution and developer experience frustrating. I object to app-store rules and payment restrictions on iOS, and to what I see as opaque distribution and approval problems on Android.

My history with CyanogenMod illustrates the problem. It was a community-built Android variant that let people remove unwanted software and customize their devices. For me at the time, modifying Android itself felt easier than building an app—an absurd situation for a platform that needs developers.

I also remember Paranoid Android and Paul Henschel, known for work in the React ecosystem including Zustand and React Three Fiber. I suspect the difficulty of mobile development helped push talented builders toward the web. That's my interpretation of his path, not something he has confirmed to me in depth.

BlackBerry 10 offered an Android runtime, showing that a different operating system could support an existing app ecosystem. It also had drawbacks, including performance and limited reasons to choose it over Android. The lesson I draw is that a new platform need not necessarily start with no apps at all.

I'd like an experimental mobile OS compatible with Android apps but designed to encourage customization, forking and building. Imagine seeing a demo, scanning a QR code and trying an app, or modifying an existing app. I want mobile to feel more accessible to experimentation, closer to the web or desktop platforms.

I worry that the incentives of the current mobile platforms make that future unlikely, and that the opportunity to build on devices with unlockable bootloaders may narrow. That's my assessment, not a prediction I can prove. I hope someone uses the opportunity to explore what a more open platform could be.

Next, a better Slack. Shared channels between companies make Slack hard to replace, but I find its reply and thread model frustrating: active old threads can be hard to find, and replying to a specific message inside one often requires manual quoting.

Agents expose more of those limitations. I want a communication tool that helps people prioritize, brings active conversations back into view, and lets an agent investigate a branch of a discussion and report back. Nested replies and a shared context for people and agents would make the workflow more coherent.

The inspiration is Facebook Workplace's post-and-comment model: a post can contain nested replies, and new activity can bring an old post back to the top. To me, a post sits usefully between a channel and a thread. Workplace had been shut down by the time of this video, so I want an open alternative that is easy to adopt and works well with agents.

Imagine an agent replying to a work item and bringing that post back to the top, instead of leaving its output buried in a hard-to-manage chat thread. I even started building something along these lines, but haven't had time to take it far. I want an open-source standard that can gradually compete with Slack.

Finally, we need more benchmarks, including strange ones made by people outside research labs. My SkateBench asks models to name a skateboard trick from a description; researchers have found the results interesting because the task mixes specialized language, grammar and spatial reasoning.

When an agent fails at your work, save the task in a reproducible form and test it again. Benchmarks could cover Git workflows, obscure programming languages, imagery or other real tasks. A measurement can show a weakness and give labs an incentive to improve; a score alone should not be mistaken for proof of real-world reliability.

I want these ideas to exist more than I want to build them myself. I may not try every project, but if people use and discuss one, I'll be interested. More broadly, use your own ideas if they excite you: try bigger solutions to harder problems, experiment, and challenge assumptions about what was previously practical.