Engineer reports loss of problem-solving satisfaction after relying on LLMs for development

The engineer describes a qualitative change in their work: the satisfaction of solving problems through iterative design and debugging is replaced by a repetitive cycle of prompt refinement and output evaluation. This shift is not about efficiency gains but about the loss of intrinsic rewards that come from manual craft. The absence of mistakes, once a source of learning, means the engineer no longer engages with the material deeply enough to internalise it. The result is a surface-level interaction with code, where the tool generates solutions but the engineer does not retain the reasoning behind them.

The cost of this change is not measured in time or lines of code but in the erosion of savviness, a term the engineer defines as practical comprehension gained through doing. Savviness is not just knowledge; it is the ability to apply knowledge in novel contexts, to anticipate edge cases, and to debug without external aid. LLMs disrupt this process by outsourcing the cognitive work of implementation. The engineer can still spot errors, but the act of fixing them no longer reinforces their own problem-solving skills. Over time, this could lead to a dependency on the tool for even basic tasks, reducing the engineer’s ability to operate independently.

The engineer notes that corporate adoption of LLMs is driven by perceived productivity metrics that do not account for long-term maintainability or technical debt. The pressure to use these tools is not limited to professional work; it extends to personal projects, where the engineer feels compelled to use LLMs despite the lack of engagement. The risk is that the industry may normalise this workflow, prioritising speed over depth. The engineer’s experience suggests that the trade-off is not just about losing passion but about losing the ability to think critically about the systems being built.

The engineer’s frustration is compounded by the realisation that their own work, including this reflection, may be used to train future models, further reducing the need for human savviness. The cycle is self-reinforcing: as LLMs improve, they generate more accurate outputs, which in turn reduce the opportunities for engineers to learn through mistakes. The engineer’s solution, for now, is to limit LLM use to tasks where the tool augments rather than replaces their own thinking, such as setting up local inference. However, this is a personal workaround, not a systemic answer to the broader question of how to preserve deep technical skills in an era of automation.