Start with what someone needs to solve
I use AI tools in development. To guide the work, I start with the requirements and the way the project is built. I want to be able to explain what needs to change and why it matters to the person who will use it. With that clear, it’s easier to ask for help and recognize whether the proposal addresses the problem.
Think of a booking form that lets someone choose a date that has already passed. They might fill in their details only to find out too late that they can’t book. Before asking for code, I’d describe what they should be able to select, what message they need to see and which time zone the business uses.
Then I’d look at where that rule needs to hold. Changing the calendar on the screen can be part of the solution, but I’d still need to check what the server accepts and what happens if the booking comes through an API or an internal panel. Following the person’s need helps me see what’s missing.
Share the context that helps
To work on that form, I’d share the related files and the project’s conventions. If a similar validation already exists, I’d start there. Building on something the team knows can make the change easier for whoever has to maintain it later.
I’d also agree on what the tool can do: proposing a change, testing it locally and deploying it are different actions. A small task doesn’t need access to everything. With real data and credentials, I’d follow the project’s rules and share only what is necessary and allowed.
Take time to understand the proposal
GitHub’s own documentation notes that Copilot suggestions can be incorrect or fail to reflect what the developer intended. It recommends reviewing the code, testing it and checking that it fits the project. That’s worth remembering when an answer looks convincing at first glance.GitHub: limitations and responsible use of code suggestions ↗
When reading the proposal, I’d come back to the form in this example: does it prevent bookings for past dates in the right places? What happens if a detail is missing? Does the message help someone correct it? If a part is unclear, it’s worth stopping to ask for an explanation. Understanding a change is part of being able to take responsibility for it.
I’d keep that review focused on the date. Reorganizing the whole form or changing its styles can wait for another task. A small change makes the decisions easier to follow and leaves more room for someone else to review it carefully.
Test with the person at the screen in mind
In this example, I’d test a valid date, a past date and what happens around midnight in the business’s time zone. I’d also try making a mistake and correcting the selection. I want to know whether the person can continue without getting lost, as well as checking that the code does what I expect.
When sharing the result, I’d say what I checked and what still needs a review. Getting the application to compile is a step; I still need to go through the form. A local test with fictional data doesn’t show what happens with a real provider in production, either. Explaining those differences helps the team decide the next step with more clarity.
Leave a good starting point for whoever comes next
When closing the task, I’d leave a short note: what the problem was, what I changed and how I tested it. If there was an important decision, I’d explain why I made it. The next person opening that code shouldn’t need the entire conversation to continue. That person might be my future self a few months from now.
I want to work with AI in a way that leaves room to understand and learn. Moving forward matters, and so does being able to explain what I deliver. When someone uses the product, they’ll trust that I took the time to care for it. That responsibility is still mine.