|
There's no doubt that LLM increases our efficiency, be it producing prototypes, generating production code, debugging our systems, or more. So, if there's no more demand or reduced work hours, some of us will lose our jobs. I certainly hope the Jevon's Paradox kicks in faster, as in months instead of years, let alone decades. If we don't consider the potential loss of our jobs, on the other hand, isn't it great that we don't have to repeatedly do what we already know how to do? I mean, how many times can we feel the thrill by writing the same CRUD applications? How many times do we have to design the same idempotent APIs? It's also a relief that we could spend way less time figuring out mitigations or root causes when there is a production incident. This reminds me of the scribes before Gutenberg's moveable-type printing press. They spent their life in scriptoriums copying the manuscripts by hand. They earned three times of the average income of their times. They were highly skilled labor. It required years of training, deep literacy, and a high level of domain expertise. Yet, history showed that even highly specialized expertise can be mechanically reproduced. That appears to be exactly what LLMs are doing for us: automating the digital equivalent of manual transcription, such as setting up the repetitive boilerplate, sketching out the standard APIs, finding predictable bug fixes. I'm not sure about others, but I have to face the same existential question today: as software engineers, where does our true value lie? Is it merely in learning, memorizing, and, reproducing patterns that others have already built. More often than not, patterns that an LLM can now piece together better and faster? Or is it in taking everything we’ve learned and applying it to solve entirely new, messy, and uniquely human problems? If our worth is tied to how well we copy the past, we are already obsolete. Our value has to shift from being human repositories of known solutions to being creators who venture into the unknown. It is, of course, easier said than done. Hence I have likely the same level of stress as other software engineers. |
It was about knowing how to fit the new use case into an existing code base, respecting the architecture, and sometimes rearchiteting the solution. How easy the latter was is really dependent on whether the code/arcitecture respected the low coupling, high cohesion principle.
Now, some of this can be coerced into LLMs but it takes work and careful study of the changes. Sometimes they get it right, many times they do not. So, you have to go back and forth with them. If you know what they should have produced.
SWE is far from dead. We just let too much slop into the codebase because we're overwhelmed by it and not incentivized by leadership to care. Code quality will likely drop to the point where even the leadership will notice and it will normalize again. There's nothing like a high profile customer calling out a problem that was vibe coded. It has started already and will be happening more and more.
Don't worry, the hype will be over in some time.