# How do we change the way our team works when we start using AI?

Faithful English translation of the Polish template.

Take one task you need to do anyway. Work through it together, from the need to a working change. You will see where an agent helps and where you still wait for a decision, knowledge or another person.

Do not assess people or count prompts. Check whether the user gets the result they need and whether the team has to reconstruct the same context less often.

## Record the model before and after

Take your current roles and one real task. The target arrangement described in The A-Team is a domain Product Owner and AI Engineers. Below, record responsibilities to agree on, without names or private information.

| Responsibility | How it works now — role and handoffs | How it should work after the change |
| --- | --- | --- |
| Need, analysis, rules and acceptance | [Product Owner / analyst / other] | [Product Owner: decision scope and missing knowledge] |
| Architecture, screen, logic and data | [tech lead / architect / frontend / backend] | [AI Engineer responsible for the whole feature; support needed] |
| Testing and quality checks | [manual tester / automation tester / other] | [AI Engineer and agents: checks; independent review; who checks the evidence] |
| Environments, releases and incidents | [DevOps / other] | [AI Engineer responsible for this area; backup and release approval] |
| Agreements and removing blockers | [Scrum Master / other] | [who makes the decision; when a short conversation is enough] |

Every row needs a responsible human. If knowledge is missing, record who will help with the first trial. Removing a job title does not do the work that role performed.

## Agree on the intent before starting

The Product Owner and AI Engineer briefly discuss the task. The agent records the essentials:

- **Who it is for and what problem we are solving:** [fill in]
- **What we will show in the demo:** [action and expected result]
- **What we are not doing now:** [task boundary]
- **What answer we need before starting:** [question and the role that resolves it]
- **Product Owner confirmation:** [confirmed / needs correction]

For an interface, identify the accepted design system and main user journeys. If these do not exist yet, show a screen prototype first. The Product Owner approves the direction; the AI Engineer points agents to the rules and components to use.

## What slows us down today?

- What are we waiting for on this task: analysis, a decision, frontend, backend, tests or a release?
- How many times do we hand the topic to another person? What must we explain from the beginning each time?
- What do we keep asking the same person because only they know why the current behaviour exists?
- Where did an agent return a result that could not be accepted without a correction or second opinion?

## How do you actually work with an agent?

- Use this task to show what you do yourself and what you delegate to the agent.
- Where do you not trust it? Show a specific result you had to correct or discard.
- Does the agent have the project knowledge it needs, or do you explain everything again in every chat?
- What takes more time: assigning work, waiting for the result, or checking and correcting it?

## What does this change mean for you?

- You enjoy writing code. What changes when the agent writes more of it? What do you still want to do yourself, and why?
- Until now, you worked on frontend or backend. What are you missing to take a whole feature through with an agent and check that it works?
- Where do you need another person so that you do not have to guess?
- Who on the team already works this way and can show the others one task from start to finish?

Before the trial, also complete the agreements in “Collect data for the review” below. The conversation reveals obstacles; the recorded data will let you check later whether the way you work actually changed.

## Let's do one task differently

Record this before starting:

- **What should work at the end?** A concrete result to show in the demo.
- **Who owns the task from start to finish?** Who will help when it goes beyond their previous area of work?
- **What will the agent do?** What can it access, and where must it stop and ask?
- **Where will it get knowledge?** Point to the description, code, rule and example. Record missing answers for the next person.
- **Who will check the result?** What will you test, what will you check in the demo, and who will decide on the release?
- **What will wait in the meantime?** The trial is not extra work after hours.
- **When will you show the result?** Set a demo date that allows time for learning and corrections.

## Complete the record of your task

Open the task you chose to work on. The agent fills in the table from its description and your conversation. When information is missing, it should ask rather than insert an invented example.

| What to record | What to give the agent or agree on |
| --- | --- |
| Task | Link to the current task and the reason you are doing it |
| Result to demonstrate | The action the user will perform in the demo and the expected result |
| Knowledge | Documents, code and answers from the person who knows how this feature works |
| Division of work | Task owner, help in less familiar areas, reviewer and the person accepting the demo |
| Waiting and handoffs | Where similar work last got stuck and which handoff you will try to shorten |
| After completion | What actually helped, what needed rework and what knowledge was still needed |
| Next trial | One change in the way you work, the person responsible and the task you will use to check it |

## After the demo

Walk through the feature live, collect small comments and address them. Then tidy up the code, run checks matched to the risk and request an independent review. “It works on screen” alone does not close the task.

Return to the record made before the trial: where did you wait less, how much work needed correcting, and where did you still need help? Can you now work through the next task, or do you still need someone beside you? What gave you satisfaction, and what got in the way? The answer should help determine the next trial and support, not serve as an employee assessment.

Record: **what we are changing, who will take it on and which task we will use to check the effect**. Materials for the agent must be approved by the team; do not include names, private data or secrets.

## Prompt for discussing the trial

```text
We are working on one existing task. Read the attached file and these sources: [links].
First separate source-confirmed facts from gaps and proposals.
Help us record responsibilities before and after: Product Owner, AI Engineers
and the agents' work. Ask about knowledge gaps and support; do not propose staffing changes.
Condense the agreements into intent, the demo result, task boundaries and questions to resolve before starting.
Show them to the Product Owner for confirmation. Then complete the trial table:
knowledge for the agent, verification, a blocker and a change for the next task.
Do not invent decisions, test results or deployments. Ask when uncertain.
First show the completed text for joint agreement. Do not change files,
accounts, permissions, environments or external systems.
```

## Collect data for the review

Use two periods of equal length and similar types of work. Take dates and results from your tasks and releases. Mark missing data explicitly; do not reconstruct numbers from memory. This is a suggested worksheet to adapt to your project.

| What to agree on before counting | Your record |
| --- | --- |
| Period before the change / period after it | [dates] |
| Roadmap goal and responsibility for the quarter | [links to agreements] |
| What counts as a completed task | [acceptance criteria; no double counting a parent and its subtasks] |
| When the measurement of time to production starts | [starting event, deployment confirmation, calendar or working days] |
| How long you observe bugs after release | [the same period for the changes being compared] |
| What changed besides using AI | [task type and size, team composition, availability, learning, other responsibilities] |

## Fill in the results

Give a source for every number. If a task does not require deployment, mark that with the reason; do not add a fictitious production date. When comparing bugs, include only changes for which the full agreed observation period has elapsed.

| What we check | Before / source | After / source |
| --- | --- | --- |
| Accepted tasks, separating features / bugs / maintenance | [counts] | [counts] |
| Time to production for each released task | [start and deployment dates, difference between dates] | [start and deployment dates, difference between dates] |
| Unreleased changes and waiting time | [count and oldest tasks] | [count and oldest tasks] |
| Tasks returned because of a confirmed bug | [count with a bug / all with a full observation period] | [count with a bug / all with a full observation period] |
| Problems after release | [release, symptom, impact, repair time] | [release, symptom, impact, repair time] |
| Quality and security checks | [version, what was checked, result, open issues] | [version, what was checked, result, open issues] |
| Use of agents in real work | [how many people in the current team; uses, accepted and rejected results] | [how many people in the current team; uses, accepted and rejected results] |
| Roadmap goal result | [what works, what is missing, evidence] | [what works, what is missing, evidence] |

Use this table to prepare a short summary: the number of observations, typical time to production and the longest cases. You can use the median: the middle value of the sorted durations, or the average of the two middle values when the count is even. Waiting time is not the number of human working hours. With a small number of tasks, show them separately.

Do not count one release several times because it contains several tasks. Finding no defects does not confirm security without evidence that the necessary checks were performed. A new scanner may have found an older issue; note the change in the scope of checks.

## Decide what to change after the review

Open a specific change that shows the problem. Are you waiting for knowledge, a decision, a review or a release? Do corrections to the agent's work consume the time saved? What could you improve on the next task?

| Decision | Your record |
| --- | --- |
| What helps and stays | [practice and the task where it worked] |
| What gets in the way | [specific case and source] |
| One change in the way you work | [what you will do differently] |
| Who leads it and what help they need | [responsibility and support] |
| Which task and when you will check the result | [link, date, method of verification] |

Record goals and responsibilities in your plan. You can use the [Roadmap and quarterly goals](team-cele-i-roadmapa-en.md) template to complete it. Assess an individual goal by its agreed result, not the number of prompts or closed tasks. Do not attribute the entire difference between periods to AI if other conditions also changed.

## Review prompt

```text
Read the worksheet and our sources from the [before] and [after] periods: [links or attachments].
First check whether we are comparing similar work. Ask about missing definitions.
Count tasks and time to confirmed production; show unreleased changes,
rework, and the actual outcome of roadmap goals and quarterly responsibilities.
Account for team availability, the bug observation period and evidence of checks.
Provide sources and the number of observations. Do not double-count tasks or releases.
Missing data is not zero; acceptance or merging code does not confirm production.
Show where the agent helped and where we had to correct work or wait.
Do not attribute the entire change to AI or assess people by task count.
Propose one change for the next task: what, who, and when to check the result.
Show it for agreement. Do not write anything to external systems.
```