Why AI Makes Strong Teams Stronger and Weak Teams Weaker

Oleksandra Bernatska at UXDX Community: Trust at Scale: Designing AI Under Uncertainty and Team Risk. Video: https://youtu.be/MzyQa-BJHmc

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

The question I've been thinking about

[00:00:07] Hello, hello everyone. Nice to hear and meet you. I'm Alex. I work from Ukraine. I'm a lead product manager, and I am working in R&D, so I'm launching a brand new product into the uncertainty with a hard usage of AI. And the question I've been thinking a lot about recently is why AI makes some strong teams even stronger and weak teams even weaker. This is something I want to discover with you today.

[00:00:43] I've been doing some insider research within my company, and also I am conducting some research around the market about how actually AI now is working for or against the businesses. And what do I see now is that all of this AI inspiration and admiration is now fading a little bit, because due to the recent research, lots of companies are saying that their investments in the artificial intelligence are not as good as they have expected. Because mostly people that are using artificial intelligence in their daily jobs, they do not verify AI outputs, and also more than half of the hard AI users admit that they are making mistakes due to AI.

[00:01:44] That's why we understand that if we lack this critical thinking moment, if we lack responsibility of decision-making, then something that is actually stimulating our brain to work faster and does some work for us can not just help us ship things better, but even do it worse to ourselves. So this is what I want to discover: what exactly sets the teams apart, the ones that can work really efficiently with artificial intelligence, and the teams that are just failing it all, just with the help of tokens and overspend on it.

How my team actually uses AI

[00:02:28] So first I conducted the survey among my colleagues in a huge team. We have developers, designers, analysts, product managers, marketers and so on and so on. So I wanted to understand how do they actually use artificial intelligence, what parts of their jobs does this technology cover and help them with, and in what cases they see some weaknesses, where do they see uncertainty, and where do they claim that this technology can make things worse.

[00:03:08] So first I asked a very simple question: how often do you actually use artificial intelligence? It means LLMs, it means any software, like development software with AI agent, or so on and so on, in your daily operational or production work on a project. And most of respondents claim that they use it every day. So this is something not just a regular tool like Slack, or maybe it is at least on the same level as Slack for any developer or product manager. And the majority of people I've been talking with agreed that AI is like a cognitive assistant for them. So it just helps people think. It helps them to understand something better.

[00:04:04] For instance, all of the software engineers in my team use AI as something like coverage on top of their IDEs, their development environments, like Cursor, like Claude. So basically they are doing almost every single one of their development tasks with the help of AI instruments. It speeds the process up. Mostly they do like it. Analysts also confirm that the majority of huge tasks that are connected to the data analysis, especially with tons of data they have to deal with, it also has been helped with Claude or with Gemini, depends on the task. And most of the requests they are reaching to BigQuery databases, they are all being done now with the help of AI, which actually speeds the process up like 10 times.

[00:05:08] Also, more operational, not such a tech jobs, specialists also use AI. Marketers use it for content generation, to maintain the same content strategy, drafts that they need to follow among their whole content vision. And it also helps to accelerate this creating posts or something like this on the scale. Product managers, such as I am, we are mostly using AI in the whole product life cycle, delegating it simple tasks that can be automated, can be delegated, like analysis of different sources of data, like analytics, like hypothesis generation and so on.

[00:06:03] Also, I adore Replit. I'm like a huge brand ambassador, and I'm building prototypes, I'm building benchmarks, I'm building the full features that then we ship on production with the help of Replit. So I'm kind of becoming more like product engineering manager rather than just product manager.

What the good AI cases have in common

[00:06:24] So to sum it all up, AI helps us a lot when the brain isn't braining, so we need to start something from scratch. And this is important, that all of these cases of very good AI usage, they have a lot in common. First, all of these tasks can be repetitive, like writing code, creating blog posts, generating some ideas, and so on. They are structured. They are mostly about dealing with a large amount of information, or they just help us to start from a blank page, just to give us a snapshot of what ideas can we do in order to solve some problem. So in other words, AI amplifies our cognitive work and not just manual work.

Where it starts enhancing mistakes

[00:07:17] So if AI enhances our thinking, then there must be some cases where it starts enhancing mistakes. I also asked my colleagues about what can be wrong with working with AI. Firstly, everyone agreed on the most common things, like context can get lost, you engage less in thinking process, everything looks logical, doesn't work, some hallucinations, and so on and so on.

[00:07:54] And generally we can divide it by two separate, like two main risk frameworks. First risk is about technical situation: is data security, is some hallucinations, data loss and so on. But alongside, there is another huge risk, which is about a more mature fear of the people that are using AI on a scale now in every company. First is that decisions can be made without business context. When you're chatting with ChatGPT or you are using Claude Code, it can understand some part of the whole process that was going on around the project, about the strategy, but it also cannot understand all of the not obvious dependencies, some of our goals that were not put on paper. So it can just bring you in the very different direction. And also another problem is delegating final decisions to AI, when the person doesn't think of it on their own, and also engage in all of the context that she or he might have, but delegating decision, like build it, launch it, and that's what we're going to ship on production.

[00:09:20] So AI rarely messes things up because it's dumb. It messes things up because it reduces criticality. Because people love not to think. It is kind of creating the situation when you are assuming that the thinking process is already finished, like AI is generating the final solution that you can take and ship. And this is a really dangerous thing. Second, it masks complexity. The generation can look logical, good, but do not cover everything that needs to be covered, that needs to be researched in order to produce a really effective, efficient solution. And the third one, it creates an illusion of completeness, kind of the thing I just said, that you think that all of the research has been already done. So even if something doesn't work, it looks like it does, and you can go with it.

[00:10:29] So AI also knows how things are usually done, but your product, your project, your team is almost never as usual. All of the products are actually living on the edge cases. So there is no standard way to create a subscription process or the email to the customer. There are a lot of specific things about each business that cannot be transferred into some standard case that AI can cover.

[00:11:04] So if we compare where AI is strong and where the problems appear, we can make this comparison matrix. If the task is typical, okay, go ahead and use AI. If it requires some complex logic, okay, we still need some human review. If there are patterns, examples of what can be done, or examples of what has already been done before, similar, and you just need to repeat this task, then AI is okay. If it is something dealing with complex architectural decisions, some implicit complex custom data, non-standard dependencies, then it looks like a human job, not the AI job.

The iceberg problem

[00:11:55] Also, some point that lots of people on my team highlighted in this survey was about this iceberg problem. Because any product has some dependencies, has some tech debt, has some unwritten decisions and agreements, and it is something that just lives in human brain, in the team's brain, but is never put down. Remember when was the last time that you have updated your Confluence page, wiki page, or your knowledge base, Notion[?] element or any other product, with the up-to-date information about all your product decisions, tasks, tests that you run? I assume this is the same pain around the majority of businesses. And this is a problem when using AI heavy, when delegating it a lot of tasks: then it just doesn't understand all of this context and just can move in a very different decision.

AI transfers the workload, it doesn't reduce it

[00:13:10] And also AI doesn't always reduce the workload for any of us, it rather transfers it. So previously we spent more time on making the first iteration, on creating, drafting, and now we can skip this, delegate, like build me an app or something, to AI, but we will spend much more time on refining the result that AI has generated. So we need to understand the way AI came up to this solution, which is actually harder than even making it yourself. So sometimes this 80% of finished work with AI can lead to this 20% that can take days or even weeks to accomplish.

Confident answers that are still wrong

[00:14:04] So, last but not the least risk and problem that any team can face working with AI: it is that AI doesn't just make mistakes, it reduces the possibility that you will understand, notice this mistake in time. What do I mean? When AI is generating the solution, it usually creates a very beautiful, engaging draft, something that you can believe. If you ask any person something the person doesn't know, you will clearly understand that this person is not aware of the topic. You will hear something like, ah, maybe, I'm not sure. But AI will never answer you in such a way. Their answer will be very specific, very trustworthy, but it can still be wrong. So this is the common problem of all AI agents, and this is a really specific problem that you must deal with, or setting up your agent in the right way, or just fact-checking everything that AI delivers to you.

[00:15:21] Another quote from the research I conducted within my team is that AI almost always agrees, and can lead you down the wrong path for a very long time, and finally, after a few hours of coding, it says, sorry, I messed up, and you have to start everything from the beginning. So to sum this all up, AI isn't just a single risk, it's a multiplier at every level, on a different risk level. And that's why the key question is no longer which tool should we use, what about budgets for AI, also another important question right now with increasing of costs for every agent. So the main question is, can our team keep up with the pace in terms of process, culture and accountability?

Do we even have rules?

[00:16:18] As a part of my research, I asked our teammates about the culture of using AI: whether they even know if we have any rules, if we have any best practices, do we have any kind of limitation on where it can be used or not. And the majority of people answered that, okay, generally we kind of understand on a personal level, but we do not have any formal rules. That's an interesting thing, because if someone is using some very risky tool and can share really sensitive information with it, usually the security team on the companies, they make those limits. But in terms of AI, that's a very different situation.

[00:17:14] It's good if the team culture, especially in small startups, it's okay when you have just common rules that everyone, maybe some unwritten rules[?], how do we use AI. It's like a personal responsibility, but it works good in a smaller scale. But on a bigger scale, with a bigger team size, it may not work as well as you might think. So the maturity in terms of working with AI in the team setting is about understanding limits of its capabilities.

A matrix of AI responsibility

[00:17:52] What do I offer? I created a small matrix, like a table of AI responsibility on the team. Something very simple that anyone can use in order to make their relationships with AI on the team level way better. So the first rule: person who uses AI is responsible for the result. So it doesn't matter, I coded this app or AI did it for me. If it was my task, my responsibility, I'm aware I'm in charge of the result.

[00:18:29] Second, the reviewer. Reviewer is responsible for quality control. It is very simple, it's a very common thing in software engineering, this code review thing. When a developer creates some codebase, and before deploying it to production, they just ask any teammate, another engineer, to make a code review, to go through it and understand whether they have some edge cases, problems, dependencies and so on. So in terms of working with AI, this is something similar. It can be some person like your marketer, and you have your peer, another marketer, that can review the prompt that you created to work with AI, or any AI agent flow, or some prototypes that you generated, you as a product manager, for instance. So this is someone, or the majority of, like some few people, a few people, product review can be held in a small group of product managers. So this is someone or a few people that can give you the proper feedback on the artifact that you are creating with AI.

[00:19:47] Third rule is about the head of engineering, or head of product, head of marketing, or team lead. So any person who is in charge of whether we are allowing AI in the different parts of our work. So this is a person that creates those rules, transfers this knowledge around their team, and maintains those standards. And fourth rule is the team. The team is responsible for following those rules that are set by their team lead, responsible for this processes, for following them, and even enriching those processes with the new cases, because AI is growing rapidly, and something that had been created and agreed on a few months ago can no longer be actual.

Five questions that make AI your amplifier

[00:20:41] So, final slide, five questions that make AI your amplifier, the five questions you must answer for yourself and your team. First, where can AI be used safely in our team? Where should AI not be used on our team? Who signs off the result of generation by AI? Where do AI decisions get reviewed? And how do we catch plausible errors? So after answering this list of questions, you will have much more clarity and stability, this insurance of the effectiveness of AI that it brings to your team. So AI will definitely amplify something in your team, but it depends on you whether this something will be strength or weakness. Thank you very much. I think I'm in time, just in time. Here is my LinkedIn. Click connect if you like, and I will be pleased to answer any of your questions.

Q&A

[00:21:54] Host: Excellent, thank you very much, Alexandra. That was a nice overview of the current state of AI in your team. It was great that you backed it up with your real research with your teams versus just general, what's happening in the marketplace. And I have a question, because this is always the one that I always think of. It's human nature to be a little bit lazy, and in particular when the AI is spitting out all of this code and it's getting better and better and better. I don't know if we can fight the human tendency to just go, ah, it's fine, it's probably good enough. So how do you push back against that laziness creeping in, of people just going and accepting that this is good enough?

[00:22:46] Oleksandra: That's a very good question, actually. And to be honest, I am in the middle of this process. I wouldn't assume that I'm a guru that knows everything about this, how to do it absolutely right. But in terms of what I'm doing and what my team is doing, firstly, we are responsible for the effective result. So if the person generates something with AI and tries to report it like it's something finished, we have this review stage. So we invite this person for the team requirement or product review, and ask to present this idea, and we ask him questions about it. And usually if the person hasn't done their homework, then it is very noticeable, and after such a roast meeting no one is ever repeating such mistakes again.

[00:23:45] Host: Okay, so pure accountability is the best way.

[00:23:49] Oleksandra: It's review, I mentioned on the matrix. It's a very, very crucial thing.

[00:23:54] Host: Excellent. And the other one that you mentioned was about recognizing the limitations of the AIs. Because I guess they're great at some things, not so good at other things, but every month, every six weeks, I don't know, depending on which company you're using, there's a new model coming out and they're better. So how are you balancing the continuous, oh, what's this model capable of, and keeping those rules in your team for what we should use it for and what we shouldn't?

[00:24:32] Oleksandra: That's like a rolling process, I would say. So if everyone is using the same tools, we are not limiting someone with the models. We just assume that Claude is better for developers, that's why they love it, they use it, so they follow all of those new skills and those team-works new features. And product managers usually use Perplexity for research, or Gemini or OpenAI for brainstorming, and so on.

[00:25:08] Oleksandra: So mostly, if you're using those tools every day, you notice if they are getting better in something, or you just read it somewhere in the news, and we have group chats where we can share some updates. So we can go ahead and try them, because it's not something that we can do after work on our free time. It is something that we can use during our working hours. That is why it's very simple to understand those updates, that then we can present them on a team level or just share on the daily meetings. So it's just, like I said, a rolling process: when something better is coming out, we share it straight away, straight ahead, and test it out.

[00:25:52] Oleksandra: But genuinely, I do not advertise using the latest updates of everything that's just coming out now. Every LLM is just fighting with each other and they are copying all of the latest features. So it's okay if you stick to one large language model that works for you. It's okay if you stick to one automation tool. It's just an instrument like any other that you might be using in your daily work. So you can take it, implement it, and iterate with it. If it helps you do your job better, or to achieve some product business result, then well done.

[00:26:40] Host: Excellent. So we're almost at time, but I guess my last question, very quick. Have you tried using the AIs to check the AIs, which is kind of the latest one, of getting them, instead of having a human reviewer, to get a second model to verify the first?

[00:26:57] Oleksandra: Yes, absolutely. Actually, now in this Replit, vibe coding tool I just shared, I'm building like the full tournament model where I have different APIs of OpenAI, Claude, Gemini, even DeepSeek, this Chinese model, where they need to fight each other to generate the better solution, and the best solution will be taken into production. So this is my vibe coding know-how.

[00:27:26] Host: Excellent, brilliant. That actually brings us to time. So thank you very much for sharing, and I hope everyone out there enjoyed it as much as I did.

[00:27:35] Oleksandra: Thank you so much.