Simply knowing how to use AI is no longer a differentiator.
What matters is not which tools you use, but which problems you can define and what you can turn into a product that actually works. A recent article I read made the same point. AI has already become a powerful tool, but conversations around development are increasingly fixated on tool usage itself rather than product value. In the end, what matters is not the technology itself, but whose problem it solves and how.
When I start work, I look at the problem before the technology.
I first check whether this feature really solves a user problem, whether we are mistaking internal inconvenience for a user issue, and whether it can still be operated after launch. In practice, this judgment often matters more than implementation. What looks like a feature request can actually be a policy problem, and what looks like a major overhaul can sometimes be solved with a single data structure. So I use AI aggressively for fast execution, but I do not see it as a tool that can replace problem framing itself.
What I want to build is not just a feature, but a product that can actually be operated.
A good product shows its real quality not in the demo screen, but in the operational stage. It only becomes a real product when it can withstand permissions, data flows, exception handling, editability, and explainability from an operator's perspective. That is why even when I look at a single screen, I think about the policies behind it, the admin structure, and the cost of maintenance. This is also why I do not separate technology, planning, design, and operations. A product is only complete when these pieces connect.
The same is true of AI usage.
What matters is not how much you use it, but where and how you place it. It is powerful for repetitive work, synthesis, drafting, and prototyping. But once you hand over prioritization, structural design, brand tone, and operational judgment, the output may become faster but also shallower. I think that is why the term Product Engineer drew so much attention for a while. The shift toward focusing on product value over code was healthy. By contrast, treating tool usage volume or automation itself as a mark of skill, as often happens now, misses the point.
What I want to show in my portfolio is ultimately the same thing.
More than what I built, I want to leave behind how I saw the problem, what standards I used to make decisions, and how I designed it into a structure that can actually be operated. In the AI era, anyone can build to a certain level quickly. What becomes more visible, then, is not speed, but the quality of judgment.
The standards I hold onto in my work are simple.
Look at the problem before the technology, design the structure before the feature, and think about operability before launch.
Rather than someone who implements features, I want to be someone who structures problems
and turns them into products that actually run.