The Product Engineer
It recently dawned on me that I might just be part of one of the last generations of software engineers who still understand code. Code—an artifact created to serve as a middleman between human intent and logic gates on a processor—is becoming less and less valuable in this post-LLM world.
Code is cheap now. You can feed a few sentences into an AI client and have it generate endless amounts of it in any language you want. You don’t have to “know” the code anymore; indeed, many no longer do. I suspect this trend will only accelerate.
I don’t see much incentive for knowing code anymore, other than helping you make educated decisions on performance or architectural topics, or perhaps identifying the subtle mistakes AI makes. But I know that’s only because of the transition period we’re in. Frontier models coupled with good AI tooling make even those skills feel increasingly niche.
If knowing how to write code is no longer the primary value-add, then how, as a software engineer, can I provide value? Well, maybe our job title needs to change.
I think we need to zoom out a bit. What we really do—and what we’re here for—isn’t just writing code. It’s solving business problems by creating digital products. Code is just the medium we’ve used thus far. As the level of abstraction has increased over the decades, so has the range of our responsibilities.
Perhaps a fitting title for us in this brave new world is Product Engineer.
Think about it: we define and architect detailed specs based on customer needs and business constraints. We know exactly the level of fidelity required for an AI to produce useful software. We are active participants in an iterative process, ensuring quality along the way and culminating in a finished solution.
Throughout this process, we communicate with various teams and divisions to bring disparate knowledge together into one cohesive whole: the product. We’re becoming product engineers, touching every aspect of the build.