For a long time, I kept asking myself: am I an engineer, a creator, a freelancer, or someone who wants to build products?
All of those answers seem partly right. I write code, and I have built quite a few websites and systems. I want to write articles that organize what I am learning and thinking about. I work with clients to turn vague requirements into results they can launch, and I have also thought about building my own product. Joining a good team and solving important problems with interesting people would also be a good option.
What really troubled me was not that these directions contradicted one another. It was not knowing which one to use to define myself.
Only later did I start to see that I had mixed together two different questions: how other people can understand me quickly, and what abilities I want to keep accumulating over the long term.
The first question needs a clear job title. The second cannot necessarily be fully explained by one.
What I Keep Doing, Again and Again
Instead of rushing to choose an identity, it is easier to look back at what I have actually done and find the common thread:
I take vague ideas, requirements, or experiences and turn them into concrete outputs that can be understood, used, shown, or delivered.
The output might be an article, a website, a content management system, a product prototype, or a workflow that a client can continue to use. The forms are different, but the underlying actions are similar:
- See the current mess.
- Clarify the real problem to solve.
- Organize a structure that can be acted on.
- Make a concrete output.
- Get feedback and revise the direction.
For example, a client website project may look like website development on the surface, but it also involves clarifying requirements, structuring content, figuring out how the back end will be used, checking accessibility, and handing the system over. The work is not truly complete just because the page appears. The client also needs to understand, trust, and continue using the system.
Organizing my own knowledge-management system is similar. The point is not to accumulate more notes, but to create a structure in which goals, actions, inputs, and AI collaboration can support real work.
These examples look different, but they are all training the same thing: making vague things clear and taking responsibility for the final output.
Externally a Software Engineer, Internally More Than an Engineer
“Software engineer” is still a useful job title. It lets a team or potential collaborator quickly understand the basic abilities I bring, and it is easier to understand than saying I am some kind of “builder.”
But a job title is more like an external interface than a complete definition of who I am.
Depending on the situation, I can describe my professional role as a “product-minded software engineer”: someone who cares not only whether the code works, but also about use cases, delivered results, and ongoing maintenance. Internally, what matters more to me is whether I am continuing to create valuable outputs that engage with reality.
These two things do not conflict.
A job title on the outside should help other people understand me quickly. My internal positioning should remind me what kind of person I actually want to become.
Different Outlets Do Not Automatically Add Up
Working on a team, serving clients, writing content, and building products can be different outlets for the same set of abilities. They may support one another, but they do not automatically form a beautiful loop.
A client project does not naturally become a case study and a method just because it is finished. An article does not automatically lead to a product or collaboration. A product prototype is not the same thing as having found a real need.
If I try to move every outlet forward at the same time, it is easy for each one to remain superficial. What I still need is a main focus for the current period: which kind of output is most worth investing in right now? How can the other activities support it instead of competing for its attention?
For example, when the main focus is a client project, I can use writing to organize the judgments that formed during the work. But I do not need to force every project to become an article just to “reuse everything.” When the main focus is exploring a product, service experience and writing can help reveal problems that keep appearing.
Integration does not mean connecting everything. It means knowing what should accumulate now, what only needs to be completed, and what can wait.
AI is very useful here. If it can read enough of my goals, projects, and feedback, it can help compare different directions, find repeated patterns, or remind me which connections are only imagined. But which path is worth investing in, and what results I am willing to take responsibility for, still need to be decided by me.
Positioning Becomes Clearer Through Doing the Work
If you also have many interests, know how to use many tools, and find that AI makes even more directions seem possible, it is easy to treat “finding the right positioning” as a prerequisite for taking action.
But positioning needs evidence, and evidence comes from things you have actually done.
You do not necessarily need to find a title that explains your entire life first. You can start by choosing an output worth completing, then see which problems you are willing to invest in, what kinds of judgments you are good at making, and for whom you want to create value.
You can write an article. You can organize a case study. You can make a very small product prototype. You can turn a messy process into a reusable method. You can also turn an experience into a perspective worth sharing.
Every completion gives you a little more evidence: Are you interested in this kind of problem? Do other people actually need it? Are you willing to take it deeper? Your next positioning is no longer based only on imagination.
My Answer for Now
If I had to give a temporary answer to “What role actually fits me in the AI era?”, I still would not rush to find a perfect title.
On the outside, I can be a product-minded software engineer. That is enough to make my professional entry point understandable, while leaving room to adjust it to different situations in the future.
On the inside, what I want to keep practicing is turning vague ideas, requirements, and experiences—through AI, engineering, writing, and product judgment—into outputs that can be understood, used, delivered, and accumulated.
Teamwork, client service, content, and products are all possible outlets for this ability, but each period still needs a clear main focus.
What I need to do next is not define myself more beautifully, but keep accumulating evidence:
Observe. Judge. Produce. Get feedback. Revise.
Then, again and again, make the work more worth doing.
If you want to continue exploring why judgment becomes more important in the AI era, you can read When Knowledge Is No Longer Scarce, What Remains. If you already know what you want to do and want to move a vague idea toward a verifiable output, you can continue with From Input to Concrete Output Is a Skill You Can Train.