A software maintainer has issued a candid statement explaining why they are no longer accepting pull requests from external contributors. The decision stems from a fundamental shift in the software development landscape driven by the rise of large language models. While maintaining a software project is often collaborative, the contributor has determined that reviewing and merging code from strangers now wastes more time than it saves. Historically, the bottleneck in development was writing code. A well-crafted pull request was worth the time required to review it because the maintainer could not easily implement the feature themselves. Today, with LLMs capable of generating code rapidly, the maintainer can produce a solid, working implementation much faster by prompting an AI agent directly. This internal process allows the maintainer to adhere strictly to their own style guidelines and coding preferences without the friction of synchronization with external parties. There are also significant security concerns. When reviewing code from an unknown contributor, the maintainer must assume potential malicious intent, increasing the risk and complexity of the review process. In contrast, code generated by an LLM under the maintainer's direct supervision does not carry the same security risks. The time-consuming back-and-forth dialogue regarding formatting, merge conflicts, and design philosophy is eliminated when the maintainer controls the generation process. Consequently, the maintainer argues that the nature of code has changed. Code is becoming an intermediate layer between human ideas and machine instructions. Since this layer is now easily generated, the value of submitting raw code has diminished. The maintainer positions themselves in the middle of the debate on coding agents, using AI to draft code while retaining full responsibility for design, review, and refinement. To redirect community efforts, the maintainer suggests several alternative ways to provide value. First, users are encouraged to provide feedback on usability, highlighting what works well and what needs improvement. Second, discussing ideas and perspectives helps the maintainer prioritize features that align with broader user needs. Third, reporting and investigating bugs is highly valuable. A detailed bug report that includes debugging steps and reproduction instructions can solve the majority of a problem. Additionally, contributors can send reference pull requests or the specific prompts used to generate them. The maintainer clarifies that while the final code will not be merged, seeing the implementation or the source prompt can be helpful for learning and refinement. Reviewing existing code to point out issues is also appreciated, as the maintainer is often bottlenecked on review time. Finally, the maintainer encourages users to fork the repository. Because LLMs make it easier to customize software, users can make necessary changes for their own use cases without waiting for consensus or permission. Forking allows individuals to pursue their own designs and implementations at their own pace. This approach saves the maintainer the time required to manage diverse use cases and compromises, while potentially allowing the community to learn from divergent versions of the software.