Devtools must be open source

Over the past five years, most software engineers I spoke to did not have any programs they had written for themselves. Engineers regularly utilize programs created by others to write programs for others. Many customize these programs using config files, plugins, or extensions, and many also use the programs they create for personal use, such as customizing their blog, home automation, or home lab.

This situation made sense to me. I have written numerous programs for personal use, and the return on this investment is often questionable. Writing code takes time, and there are always more important tasks to focus on. Maintenance of custom software after a year can be extremely painful. At times, I have abandoned my custom software and opted for standard environments to produce code more efficiently.

In my early years at Google, I even lacked a personal computer. Today, personalizing software is remarkably easy. There are two main prompts that enable this: first, agents can generate code for specific use cases and automatically synchronize changes with upstream releases. This reduces the initial effort to personalize software and makes it easier to maintain ongoing customizations.

The two prompts can be integrated into an agent, allowing users to personalize software without extensive programming knowledge. By loading the prompts into a skill, users can make adjustments through simple text instructions. For example, one can personalize an agent by stating "make Shelley's UI high-contrast," and the agent will handle the customization without any additional setup.

I have been developing a personal project called meat.dev, which aims to review code written by agents before it is deployed to production systems. As the underlying models improve, the focus of my review has shifted. Human reviewers typically struggle with identifying edge cases, such as ensuring error messages are informative and nil-checks are handled properly.

However, with improved models, these edge cases are more reliably addressed by the models themselves, leaving less need for manual review. To streamline this process, I created a tool that utilizes language models to filter out unimportant details from code diffs, enabling me to focus on the most relevant changes. Nevertheless, this tool has a couple of drawbacks: it requires a terminal interface, and the time taken to process diffs using an LLM can be significant.

Ideally, I would like the tool to be integrated directly into the Shelley environment, processing commits in the background as they are created, and providing a toggle to enable or disable the tool. By implementing this integration, I can review diffs more efficiently within Shelley without the need to switch between different interfaces or wait for the tool to complete its processing.

This demonstrates the power of agent-driven personalization in software development. With the right source code, agents can significantly enhance the capabilities of software by automating the process of understanding, modifying, and tailoring the codebase to specific needs.