LLMs and xfwl4

The event is a first-person account of LLM-assisted development in an open-source Wayland compositor. The author treats LLMs as a productivity multiplier for understanding legacy code and validating new implementations, not as a replacement for writing code. This distinction matters because it preserves the developer’s agency over the final output while offloading tedious analysis tasks. The workflow described, iterative prompting, manual coding, and LLM-powered code review, is reproducible without requiring deep integration into proprietary platforms.

Legal uncertainty around LLM training data is the most immediate risk for engineers. The post highlights that US law currently permits training on publicly available data, but the status of LLM outputs that resemble existing code is unresolved. For projects under copyleft licenses like GPL, this creates a compliance gray zone: if an LLM generates code similar to GPL-licensed work, the developer may inadvertently violate the license if they don’t attribute or comply with its terms. The risk is asymmetric, larger companies can absorb legal costs, while individual maintainers cannot. Until courts or legislatures clarify these issues, engineers must either avoid LLMs for licensed codebases or accept potential liability.

The environmental and hardware supply impacts of LLMs are structural costs that engineers now inherit. Data centers for LLM training and inference consume significant electricity and water, often with local communities bearing the infrastructure costs. Meanwhile, the AI-driven demand for GPUs and high-capacity RAM has distorted the consumer hardware market, making upgrades prohibitively expensive. These effects are not temporary; they reflect a shift in how computing resources are allocated. Engineers who rely on LLMs are complicit in these outcomes, even if they mitigate them by using the tools sparingly or choosing providers with better sustainability practices.

The post reveals a pragmatic tension: the author acknowledges the ethical discomfort of using LLMs but continues because the utility outweighs the guilt. This calculus is likely shared by many engineers who use these tools for specific, bounded tasks rather than wholesale automation. The described workflow, using LLMs for research, planning, and validation, minimizes the risk of over-reliance while still capturing productivity gains. However, it also assumes the developer has the expertise to recognize when the LLM’s output is flawed or misaligned with the project’s goals. For less experienced engineers, this approach could amplify errors rather than reduce them.