Programmers risk losing their enjoyment and fundamental skills as large language models increasingly handle code generation, according to a personal reflection from a Haskell developer shared in the Haskell Community forum. The author describes feeling that the programmer's role is shifting from being an active creator to a mere cog in a machine, where specifications are simply handed to LLMs for implementation. This degradation threatens the intrinsic satisfaction derived from expressing thoughts through code, particularly in languages like Haskell where the process of coding itself is a source of pleasure independent of the final product.
The author proposes a specific workflow to counteract this trend: developers should continue writing code manually while using LLMs only for preparatory work such as planning and research. For planning, LLMs can convert discussions between domain experts into actionable todo lists or organize test results into fix-it plans, but crucial decisions must remain with the human programmer. For research, developers should verify LLM findings independently using traditional search methods rather than accepting agent outputs as facts. Most importantly, the author insists that humans must perform the actual coding, stating 'Plan together, but then you code' and suggesting that LLMs handle incidental tasks around the programmer's workflow rather than dictating the process.
The author further recommends implementing automated review cycles where a second LLM checks the first's outputs for errors or omissions, creating a feedback loop similar to generative adversarial networks in image generation, to catch issues before they reach human review. This approach requires caution, however, as the author warns against over-reliance on frontier models from major tech companies due to their substantial environmental costs, lack of transparency regarding resource usage, and unpredictable token limits that can abruptly halt work. While acknowledging that LLMs may perform as well as or slightly better than humans in some aspects, the author argues they would need to be vastly superior in reliability, resource efficiency, and accountability to replace human developers at their core activity.