In this chapter
In my approach, the team is built around two roles: a domain Product Owner and AI Engineers. The Product Owner understands the problem and decides what should be made. An AI Engineer leads the change through the whole application with agents, checks it, and prepares it for release.
From many roles to ownership of the entire change
Teams previously split roles in various configurations, sometimes with several functions in one person. Today I arrange them like this:
| Before | Now |
|---|---|
| Product Owner and analyst | A domain Product Owner with an aptitude for analysis. Explains the need, rules, and exceptions; sets priority and accepts the product behaviour. |
| Tech lead / architect | An AI Engineer makes and records technical decisions. When shared parts change, it is clear which engineer leads the decision. |
| Frontend and backend developer | An AI Engineer delivers the whole feature — screen, logic, and data — using agents. |
| DevOps | A named AI Engineer owns environments, deployment, incident observation, and the ability to roll back a change. |
| Manual and automation tester | An AI Engineer with agents prepares and runs checks, goes through the application, and fixes defects. Another agent performs an independent review; the Product Owner checks the result from the user’s perspective. |
| Scrum Master | The team agrees work without a separate ceremonial role. Short conversations decide, remove a blocker, or show a result. |
This describes my direction. I do not assume a separate tester or permanent handoffs between frontend and backend. Tests, architecture, and maintenance still have an owner. An AI Engineer must assess agent output and recognize when help is needed.
Product Owner and AI Engineer: agree the intent
Open one current task and the application. The Product Owner shows the problem; the AI Engineer checks that they understand the expected result. If the subject is large, choose the first slice for a demo.
A short conversation should leave four agreements:
- Who is this for, and why are we doing it? What gets in that person’s way today?
- What must change? What result will we show in the application?
- What are we not doing now? Where does this task end?
- What needs an answer before we start? Which rule or exception is still unclear?
AI can write a great deal of text. I need to extract the point from it. Ask the agent for a short summary and have the Product Owner confirm it represents their intent. When something is unclear, talk rather than pass generated descriptions back and forth. The agreement stays with the task; the AI Engineer returns with a working slice to show.
Set the design early
At the beginning, prepare the design system well: shared interface elements and rules for buttons, forms, colours, typography, and screen behaviour. In a working product, start with what you already have.
- Choose the user’s main action and show a visual trial of its screens. Include an empty state, error, and phone if it will be supported.
- The Product Owner approves the flow and visual direction. A designer can help at this stage.
- The AI Engineer records the accepted rules and points the agent to existing components for future views.
The Product Owner then leads product and interface decisions, and the AI Engineer implements them with an agent using the same rules. I do not need a separate visual-design handover for every change. When a feature does not fit the design system, agree the extension and record it for later tasks.
Check what needs to change in your work
Review the history of the last task: who did you wait for, how many times did work move on, and what had to be explained again? In the next task, try to remove one such handoff. Agree the lead, the Product Owner who accepts the result, and help in a less familiar part of the application.
Have one person show a conversation with an agent: instruction, result, and correction. If someone does not trust results or misses the satisfaction of writing code, discuss it using a concrete example. “Now everyone does everything” does not prepare anyone for the work. Plan time for learning and a joint check of the first change.
Record a baseline before the trial: number of tasks, time to production, and returns caused by defects. Do not guess missing data. How to measure the effect of work with AI shows what to collect and compare.
Connect the task with quarterly goals
We look at goals in the roadmap, the plan of important product changes. People also have individual goals and a responsibility scope for the quarter. For a current task, I want to know which goal it moves us toward and who owns the result.
In the plan, I separate team goals, individual goals and a weekly review of priorities. You can use this structure in your own work:
| What you agree | What to record | How to connect it to work |
|---|---|---|
| Roadmap and team goals | Need, expected result, order, horizon, owner, and collaboration | Tasks lead to the right goal; status alone does not replace a result description. |
| Individual quarterly goal | Result, responsibility scope, verification method, and needed support | It is clear what the person owns, what they agree with others, and how the goal fits alongside current work. |
| Weekly review | What was completed, what blocks the goal, and the next step | Open real tasks and evidence, then make the needed decisions. |
This is not a race to close tasks. One person may deliver a feature, another may own area stability, and a third may remove dependence on one person’s knowledge. Each needs a clear result. The agent helps with work, but responsibility for the goal remains with a human.
Download · Text fileRoadmap and quarterly goals — team and individual document templatesteam-cele-i-roadmapa-en.mdDownloadDownload the file and attach it to the project conversation. It has tables for your roadmap, team plan, individual goal, and weekly review, including evidence fields and links between documents. If you already have a Confluence plan, complete it instead of creating a second list of the same goals.
Read the template and our plan [sources]. Show the connection: roadmap goal → quarterly team goal → individual goal and responsibility → current tasks. Include maintenance and required support. Point out where the intended result or its reviewer is unknown. Do not invent goals, dates, or people’s assignments. Prepare a proposal for completing the existing plan and a weekly-review table. Show them for joint agreement without writing to external systems.
Run a trial and discuss the result
Download · Text fileConversation about moving to AI-supported workteam-ai-transition-en.mdDownloadDownload the file, attach it to the conversation with the agent used in the project, and paste the prompt. Do not enter private matters or employee data. The template is meant to help a conversation, not assess people.
Let us take one current task: [description]. Read the attached file. Ask what we are waiting for, to whom we hand the task next, and what we explain again each time. Then ask what we already do with an agent, where we do not trust it, and where we need another person’s help. Ask about one subject at a time. Do not judge people or propose staffing changes. At the end, show the division before and after: what the Product Owner agrees, what the AI Engineer leads, what agents do, and who checks the result. Record the intent, scope, and what we will show at the demo briefly. Include learning time and what already works. Show the agreements for review before writing them into team documents.
What should remain after the conversation: responsibilities before and after, one task with agreed intent, a lead, available support, and a demo date. After the trial, return to the questions: what was faster, how many corrections were needed, and how did people experience the work? For legacy, also include knowledge transfer from people who know the old system.
Next: GTM and One Man Army specialists
In my view, software development will become cheaper, while reaching people with it and delivering value to them will become more important. That is why I see a place for a GTM Engineer — from *go-to-market*, meaning bringing a solution to market. I use this term to combine knowledge of technology and AI with an understanding of whom to help, how to deliver a solution, and how to sell or improve it.
I also see a place for One Man Army specialists: people who know their domain and can use AI to build a useful solution independently. This is my forecast, not a guarantee of lower costs for every project.
Apply this to your roadmap: choose one feature and record who will reach its users, how they will show its benefit, and how you will know users have started using it. Deployment alone does not answer those questions.
How our work on AppEnergo changed
We started building AppEnergo before the AI boom. Nearly 15 people worked on the project, together with an external software house. Over time, we began using AI inside our organisation, and I increasingly saw that our existing way of working was not keeping up with the new possibilities.
Ceremonies, analysis and knowledge handoffs between people took too long compared with how quickly we could already test ideas and introduce changes. We needed to change the entire workflow, rather than simply give an agent access to code.
Today, three or four of us develop AppEnergo. From my perspective, the pace of development is similar to before. This is my observation from leading the project, not a productivity measurement or a comparison of identical scopes of work.
The stages are still recognisable: understanding the need, analysis, implementation, checking and handing over the result. What changed is how we move through them and how we communicate. In our daily work, many transitions between them are several times faster. Responsibilities previously spread across several people are now more often combined in one person supported by agents.
Our old, rigid split between frontend and backend has disappeared. Everyone effectively works fullstack — through the interface, logic and data to deliver a working part of the product. This does not mean everyone has identical knowledge in every area. A wider scope of work still requires collaboration and checking the result.
My direction is clear: code will not be created the way it was before. The transition requires trials, learning and corrections, but simply adding AI to unchanged processes is not enough. For me, there are no half measures in the target way of working — although we reach that change in stages, on real tasks.
That is why I also begin the AI-first conversation with people: what gives them satisfaction, what they need to trust the results, and how to prepare them to take responsibility for a broader outcome.