I build software and enjoy learning along the way.

Question I ask myself

• What problem does this concept solve?
• Where would I use it in a real project?
• What is the smallest example I can run first?
• Which official document or reliable source should I check?
• How can I test it before putting it into the main project?
• Can I explain what works, what does not, and why?

What I do

I usually start from the problem and the use case. I want to know what the concept is for, where it appears in a project, and what kind of result I should expect.

Then I check reliable sources and try a small example first. I prefer a simple version that I can run, test, and adjust before bringing it into the main project.

When I apply it to a project, I keep the first version small. I check the result with sample inputs, test cases, console output, UI behaviour, or other evidence that fits the feature.

I feel more confident with a technical concept when I can explain how I used it, what changed, what worked, and what I would improve next.

Question I ask myself

• What am I trying to achieve with AI in this task?
• Do I understand the project structure before asking for changes?
• Is this a learning question, a coding task, a review task, or a debugging task?
• Have I given enough context, constraints, and examples?
• Which files, behaviours, or design choices should stay unchanged?
• How will I verify the result through running, testing, diff review, or manual checking?

What I do

I try to keep a positive and practical attitude toward AI tools. I use ChatGPT and Gemini more for learning, discussion, and shaping ideas, while I use Codex, Claude, and Cursor more for code review, project changes, and implementation support.

For coding tasks, I do not start with a vague request. I first try to understand the project structure, the goal, and the parts that should not be changed. Then I write the prompt more like a small task brief, with context, constraints, expected output, and verification steps.

I also keep learning how to use these tools better, especially from official guidance and structured courses. For example, I have looked into engineering-style prompting, AI agent skills, and Claude Code learning materials, because I want my use of AI to be more deliberate than just asking for quick answers.

After the tool gives an answer, I still check the result through running the project, reviewing what changed, testing the behaviour, and deciding whether the change actually fits the project.

Question I ask myself

• What is my part of the task?
• What result does the team need to finish?
• What is the current priority?
• Does my work depend on someone else?
• What have I tried if I get stuck?
• Who should I speak to if the issue affects the team plan?

What I do

When I work with others, I try to understand both my own task and the wider result the team needs to deliver. I pay attention to priorities, dependencies, and how my work connects with other people’s tasks.

In university group projects, I often took an active role in keeping the work moving. I helped arrange meetings, split tasks, check progress, and make sure the final version could still be completed on time. When someone was blocked, I tried to discuss the problem early, adjust the plan where needed, and help the team move forward.

If I get stuck, I try to understand the issue first before asking for help. I prefer to bring what I have tried, what I think may be wrong, and what options I can see, so the conversation can move toward a solution faster.

My part-time work trained a different side of teamwork. In a busy store environment, I had to react quickly, communicate clearly with colleagues and customers, and adapt when tasks or rules changed during the day.

Question I ask myself

• What real user scenario is this feature trying to support?
• From the user side, what is the most natural path?
• From the developer side, how should the data, state, and rules be handled?
• From the tester side, where is the feature most likely to break?
• Who is allowed to use this feature?
• Are there permission or eligibility limits?
• Can one user repeat the action?
• What happens when the limit is reached?
• What should the system do if the input is invalid or the state changes suddenly?
• Am I only implementing the happy path?

What I do

When I think about a feature, I usually start with inside-out thinking. I look at it from three sides, user, developer, and tester.

From the user side, I think about whether the feature feels natural to use, what the core need is, and what may happen in a real situation. For example, with a shopping cart, I would not only think about how to add items. I would also think about what happens if a user adds items before logging in and then signs in later.

From the developer side, I think about how the feature should be implemented, including the data, state, rules, and page behaviour behind it. From the tester side, I think about which parts of this specific feature are most important to check, based on how the feature is meant to work.

This helps me think beyond the happy path and connect the feature with real user behaviour, implementation details, and testing focus.