Your expertise should be visible in the work

A developer, a QA lead, and someone in support can ask an AI agent to review the same feature and come back with almost the same list of issues.

The titles are clear. The descriptions sound professional. There are recommendations and acceptance criteria. Everything looks ready to assign.

But where did their experience enter the work?

That is something I have been noticing, and it concerns me. We have people who understand different parts of the product, know its history, and see problems from different angles. Their work should benefit from that knowledge.

Our expertise should change what we notice, what we investigate, and what we ask the team to do next.

The first answer still needs work

“Improve error handling.” “Add more tests.” “Optimize performance.”

These can be useful starting points. On their own, they tell us very little about this product. Which failure occurs? What do the existing tests miss? Where is performance affecting someone?

An experienced person should be able to take the investigation further. They know which assumptions to question, where a similar change caused trouble before, or why an apparently sensible recommendation does not fit the system.

An issue is a request for someone else’s attention. Filing an unexamined suggestion passes the investigation to the next person. They still have to establish whether the concern is real and whether the proposed fix would help.

We may have created more issues without understanding the product any better.

What experience adds

Imagine a contact import that times out. The user retries it and ends up with duplicate contacts. A generic issue might say:

Improve import error handling. Add clearer messages, automatic retries, and more tests.

That sounds reasonable. Automatic retries could also repeat the very action that created the duplicates.

Support, QA, and engineering each have something to investigate before we decide what to do. In this example, their contributions could look like this:

One problem, several responsibilities

“The import timed out. I tried again. Now I have duplicates.”

SupportWhat happened to the customer?

Evidence to gather

Confirm the sequence with the customer: timeout, retry, then duplicates. Check whether earlier advice encouraged retrying.

Judgment to contribute

Explain what the customer could not finish and what cleanup they now face. Keep their observations separate from a suspected cause.

QAUnder what conditions does it fail?

Evidence to gather

Interrupt an import after some contacts are saved, then retry it in a test environment. Record the setup and resulting duplicates.

Judgment to contribute

Show which conditions reproduce the problem and which remain untested. Define checks for safe recovery and existing records.

EngineeringWhat mechanism explains the failure?

Evidence to gather

Trace how contacts are saved and how retries work. Check whether a retry recognizes records the first attempt already created.

Judgment to contribute

Recommend a recovery approach that fits the data model. Explain what must change beyond the error message.

LeadershipWhat decision should we make now?

Evidence to gather

Review the verified failure, customer impact, ways to limit the damage, and effort needed for a fix.

Judgment to contribute

Decide what to address now, who owns it, and when to check back. Explain any risk the team is accepting.

Now the issue can say something specific: “Retrying an interrupted import can duplicate contacts already saved.” We have a behavior to reproduce, a consequence to explain, and a result the fix needs to achieve.

An agent can help gather that evidence, trace the code, and run the checks. Our contribution is in directing the investigation, questioning what comes back, and deciding whether the result supports the recommendation.

Stay involved in what comes back

A better prompt helps, but the responsibility continues through the work.

Give the agent the context you have: the customer’s goal, relevant product history, known constraints, and previous failures. Ask it to test your explanation, consider alternatives, and show the evidence behind its conclusions.

A CHI 2025 survey of 319 knowledge workers found that greater confidence in AI was associated with less reported critical thinking. It is self-reported evidence, but it is a useful reason to examine how readily we accept an answer.

Before passing a recommendation to the team, we should be able to explain:

• What did we find, and how do we know?
• Why does it matter in this product?
• What should we do next, and why?
• What would show that the problem is resolved?

Often a few sentences are enough. If something is still a suspicion, say so. An urgent concern can be raised before the investigation is complete.

Then follow the result. Check whether the change solved the problem and record what should inform future work. That might be a regression test, a support note, or better context for the next agent session.

Your experience should show in what the team understands better because of your work.

Leave room for good work from anyone

A support colleague can identify an architectural problem. A developer can notice something confusing in the user experience. A junior colleague using AI can produce a better investigation than someone with years of experience.

We should welcome that. Responsibilities give us areas to pay attention to; they should not prevent us from contributing elsewhere.

People can also reach the same conclusion for good reasons. An AI answer may be correct as written. There is no value in rewriting it just to show that we did something.

What matters is whether we examined it against the actual situation. Experience should help us explain and test a recommendation, and recognize when someone else has found a better answer.

This applies to leadership too

Working across development and team decisions, I need to hold my own suggestions to the same standard. If I turn every recommendation from my agent into an assignment, I am creating the same problem for everyone else.

A suggestion can carry extra weight because of who sends it. I need to be clear about what I have verified, what I am asking someone to investigate, and what I am deciding. The people closest to the work need room to challenge it.

We also need to recognize the work behind a useful recommendation. Someone who rules out a misleading concern or combines several reports into one diagnosis may create fewer issues while saving the team considerable effort. Counting output alone misses that contribution.

I want us to use AI as deeply as we can, while staying actively involved in what we ask it to do and what we accept from it.

The next issue we create should leave the team with a clearer understanding of the problem and a useful next step. Our experience should be part of how it gets there.