Even as a developer who uses RPI skills with models, I watch them write utilities that already exist, make inline functions when a utility class that it would logically fit in goes untouched. Bloat isn't just because of vibe coders, it's the nature of the technology. Writing code by hand is like drawing with a pen. The developer plans ahead, gets the shape of the code in his mind and writes just what is needed. A process of genesis. When using an LLM this same coder architects the shape of the code and asks the LLM to carve it from all the examples in its training data. A reductive process. The problem is that sometimes the shape doesn't confirm to the training data or the model doesn't share the developers architectural aesthetic. At this point imposter syndrome can set in and the developer accepts what the LLM wrote without the careful planning and thhought that went into the original approach. This leads to missed edges and curlicues in the code where an approach may not be fully understood (bloat). Since we're approaching the limit of quality that LLMs will reach, this will be what keeps software developers employed. Either building new systems or logically correcting brownfield codebases that have bloated over time. Having the patience to read through the bloated code and direct refactoring as well as being able to spot bloat/tech debt early will be the fundamental employable skills.
Even as a developer who uses RPI skills with models, I watch them write utilities that already exist, make inline functions when a utility class that it would logically fit in goes untouched. Bloat isn't just because of vibe coders, it's the nature of the technology. Writing code by hand is like drawing with a pen. The developer plans ahead, gets the shape of the code in his mind and writes just what is needed. A process of genesis. When using an LLM this same coder architects the shape of the code and asks the LLM to carve it from all the examples in its training data. A reductive process. The problem is that sometimes the shape doesn't confirm to the training data or the model doesn't share the developers architectural aesthetic. At this point imposter syndrome can set in and the developer accepts what the LLM wrote without the careful planning and thhought that went into the original approach. This leads to missed edges and curlicues in the code where an approach may not be fully understood (bloat). Since we're approaching the limit of quality that LLMs will reach, this will be what keeps software developers employed. Either building new systems or logically correcting brownfield codebases that have bloated over time. Having the patience to read through the bloated code and direct refactoring as well as being able to spot bloat/tech debt early will be the fundamental employable skills.