“Did You Do This with AI?”

I've noticed that when people learn a piece of work was prepared with the help of AI, the way they look at it sometimes changes. Work that was seen as a success a moment earlier can start to be re-evaluated in people's minds once they hear which tool was used.

“Did you do this with AI?”

Sometimes there's simple curiosity behind this question. Sometimes there's an unspoken doubt: “How much of this did they actually do themselves? Do they really know this, or did they just get to the result by using the tool?”

It's as if a stereotype is forming around the use of AI. An opinion takes shape based on the tool that was used, before the person's knowledge, decisions, and effort in the finished work are fully seen. And the person who feels this way may not always be able to explain why. Maybe it's habit, maybe uncertainty, or maybe a quiet, inner wish to protect the value of their own expertise.

To me, this is the part worth talking about. As companies add AI to their plans for the future, what ideas about working with it are taking shape in people's minds?

1. The Rush to Get a Slice of the AI Pie

I can understand why companies are interested in AI and want to include it in their vision for the future. They don't want to be left out of a technology that could speed up work, reduce costs, and open the door to new products. Add the fear of falling behind the competition, and the topic can sometimes stop being an assessment of needs and turn into a race that has to be joined in a hurry.

But the sentence “We're going to integrate AI into our business” leaves many questions unanswered on its own.

Which work will we use it for? What is slowing us down in our current process? How will we measure success? Will the time employees save really be freed up for other work, or will checking the new system become an extra burden on top of their existing job? What will it cost, and how secure will it be?

These questions need real answers in practice. For example, if we want to shorten the time it takes to prepare a report, we need to look at the time spent checking and correcting it as closely as the time spent drafting it. A fast first draft doesn't, on its own, show that the whole process has become more efficient.

Then there's the question of how the company conveys this goal to its employees. If leadership talks about innovation while, within the team, only manual effort still counts as visible work, employees may find it hard to tell which behavior will be valued. They may be expected to use AI and yet, when they say they've used it, feel the need to prove their own contribution separately.

This is where we see how well the vision matches the day-to-day culture of work.

2. Where People Fit in the Integration Plan

Changing a system also touches the habits of the people who work with it. Over the years, people don't just learn tools. They build a structure around how they do their work, what they feel confident handling, and what they're known for on their team.

One person's strength might be writing complex queries. Someone else might hold an important place on the team because they can prepare the reports everyone else struggles with. When AI makes part of these tasks easier, a person may also start to wonder how their own role will change.

“I spent years learning to do this. If someone with less experience can now produce a similar result, where does that leave my experience?”

I find this a very human question. Wanting to protect the meaning of the time spent learning, the effort put in, and the expertise gained is an understandable feeling.

Concerns about job security can come on top of this. When employees are offered a system that will speed up their work, they may think not only about the time they'll save but also about what the company will do with that time. Will they take on more meaningful responsibilities? Will more work be expected of them? Or will the need for them shrink over time?

When these uncertainties aren't talked about, I'm not surprised that people keep their distance from a new tool. Sometimes what looks like a technical discussion also holds unanswered questions about a person's future.

That's why an integration plan should make as much room for open communication as it does for training. What is expected of employees, how their tasks will change, and how they'll be supported in learning new methods should all be made concrete. People embracing a goal in a presentation and people trusting that change in their own working lives are two different processes.

3. “Toil Syndrome”: Looking for Effort in Familiar Forms

In this piece, I use the name “Toil Syndrome” for the tendency, when evaluating a piece of work, to treat the toil that went into it as the measure of its worth.

Working long hours, wrestling with problems one by one, trying something again and again… These make effort visible. When we can see how hard a piece of work was to prepare, it can be easier to make sense of the person's contribution.

When AI is used, though, some parts of that process disappear from view. The result can appear in a short time. And because we sometimes can't see the thinking, deciding, and checking that happened in between, we may assume the contribution was smaller.

The stereotype that forms here might be: “If they used AI, they took the easy way out.” In some cases, I think it goes even further and turns into a feeling that it's “something like cheating.”

This thought doesn't have to be a conscious stance. Someone can accept that AI is useful and still feel a quiet hesitation when looking at work made with it. That's because, in the way of working they know, competence mostly shows itself through visible technical effort. They may not yet know where to look for the same competence in the new way of working.

There's also the feeling of comparison. Seeing someone else finish in a short time a task that took us long hours of effort can make us think back on the work we put in. Our own experience can then creep into how we judge the method they used.

I think it's important to notice this feeling, because it makes us question which yardstick we use when we evaluate work. Are we looking at the time spent, at whether the person understands what they did, or at the quality of the result?

Of course, concrete questions about accuracy, security, or whether the person really understands the subject still need to be answered. The stereotype comes into play when we reach a conclusion just from learning that AI was used, without examining the answers to those questions.

4. The Changing Workload: A Data Analyst's Example

Let's look at a specific role. Imagine a data analyst working with sales data from different sources. They merge files, standardize date formats, examine missing records, write SQL queries, and finally build a dashboard.

This work involves both technical knowledge and repetitive tasks. At some steps the analyst has to think carefully, since analytical thinking is indispensable in this role; at others, they're repeating operations they've done many times before.

AI can support a large part of this process. It can draft code for the cleaning steps, write queries, help investigate inconsistencies, and make it easier to automate recurring checks. This way, the analyst may not need to write every technical step from start to finish.

But the choices still remain. Should missing records be deleted? How should returned products be subtracted from sales totals? Do two similar customer records really belong to the same person? Is an unusual value an error, or a real situation worth investigating?

Answering these without thinking can produce a report that looks neat but is wrong.

For example, a query written by AI might count the same sales record more than once when joining tables. The dashboard works, and the charts look perfectly fine. The analyst needs to notice this possibility, compare the results against the source totals, and find the cause of the problem.

The person's technical knowledge is still at work here. They also use it to steer what's being done and to test the result.

In a well-designed process, the time saved can go toward exploring what the findings mean and contributing to business decisions. Less repetitive work can have a positive effect on costs and on how much work gets done. Accuracy can also improve with the right checks, but using AI doesn't guarantee that on its own.

When evaluating work like this, I think the analyst's decisions, the checks they ran, and the explanation they give should be made visible. Looking at these is a healthier way to understand someone's contribution.

5. The Value of Concepts as Tools Change

Learning technical tools matters. The mistakes we make and the solutions we find while working with those tools teach us something, too. Beyond that, it is also important to focus technical knowledge on improving systems, by benchmarking and validating the output of any work where AI is used.

But as systems that make tools easier to use continue to develop, the value of understanding concepts becomes clearer to me.

We need to know the difference between code that runs and code that solves the right problem. Staying with the same example, we should be able to understand how to handle missing data, what a metric actually measures, and under which assumptions it is meaningful.

Cybersecurity works in a similar way. A tool can summarize an alert or suggest next steps for an investigation. To evaluate those suggestions, we need to understand access permissions, how the system works, and what the risk in question actually is.

Seen this way, I think the uses of technical knowledge are expanding. Beyond producing things ourselves, evaluating what's been produced and stepping in when needed are becoming part of our competence.

This needs extra care during the learning phase. As getting results from AI becomes easier, we can be lulled by the confidence of having finished something we don't actually understand. That's why, alongside being able to say “It works,” it's important to be able to say “I can explain why it works this way.”

Being able to use the tools, understanding the concepts, and applying them to a real problem create value together.

6. The Bubble Debate and a Reminder from the Internet Era

How many of the expectations surrounding AI will come true is open to debate. There may be failed products, and investments that don't meet a real need. Expecting every new feature to bring a major transformation doesn't seem realistic to me.

Even so, while this debate continues, we need to keep evaluating the uses that are proving valuable today.

The spread of the internet brought major changes to working life. Some business models declined and some tasks disappeared, while new professions, services, and ways of working emerged. Over time, people learned to do their work differently.

We can't say for certain that AI's impact will play out the same way. But this example reminds us that the methods we're used to today don't have to be permanent.

For me, acceptance starts here: seeing that the change is real, trying to understand what it affects, and developing our own knowledge accordingly. Concerns about job losses should stay part of this conversation, too.

I don't think AI needs to be added to every process. But I find it increasingly necessary to know it well enough to judge where it makes sense to use it. That way, we can make decisions based on the benefits and problems we actually see, beyond the hype or the stereotypes that have formed.

7. As the Work Gets Easier, the Responsibility Remains

Alongside my positive view of AI, I also take seriously the question of how far we can trust what it produces. Both are possible at the same time.

Before a report, a piece of code, or an analysis is used, it needs to be properly verified. A result matching what we expected may not be enough; our own expectation could be wrong, too. That's why source data, comparisons, and independent checks matter.

Security also needs to be considered from the start of any integration. It should be clear which information can be shared with which tools, how customer data will be protected, and what permissions the system will be given. Giving a tool more access than it needs just to get the job done may save time but create other problems.

This is no longer a hypothetical risk. As AI tools move from answering questions to reading email, browsing the web, and acting on our behalf, more of the danger hides in the content they read. With indirect prompt injection, instructions concealed in a web page, a document, or an email can steer an assistant into leaking data or taking actions its user never asked for. In March 2026, Palo Alto Networks' Unit 42 reported that attacks like these are already live on the open web. The connectors that extend an agent's reach widen the attack surface, too. MCP servers, which link AI agents to files, databases, and business tools, are one example: when Trend Micro researchers audited nearly 10,000 public MCP servers, they found security issues in more than 2,000 of them, most often missing authentication.

Some of the risks are far less technical. IBM's 2026 Cost of a Data Breach report found that incidents involving shadow AI, meaning AI tools employees use without approval, more than doubled in a single year. It also found that 92% of organizations hit by an AI-related breach lacked proper access controls for their AI systems. Code written with AI deserves the same scrutiny. In Veracode's 2026 tests of more than 100 models, nearly half of the coding tasks produced code with a security flaw, even though almost all of it was syntactically correct. In security terms, that is the gap between “it works” and “I can explain why it works.”

Attackers are adopting AI as well; IBM found that one in four malicious breaches were AI-enabled, most often through deepfake impersonation. Yet the same report shows that organizations making extensive use of AI and automation in their own security operations cut breach costs by nearly $2 million on average. So the lesson isn't to stay away from AI. It's to give each tool only the access it needs, keep a human approval step for sensitive actions, and know which tools and connectors are actually running in our systems.

I think these need to become part of how we work. If employees know which tools they can use, what they need to check, and at which stage someone else's review is needed, a more solid process can take shape.

Then AI use can also be discussed more openly. People can explain which parts of their work they got help with and which decisions they made themselves. And the team can ask more concrete questions when evaluating that work.

When someone says “I prepared this with AI,” I'd like there to be room for them to then walk us through their work. I'd like to hear what they were trying to solve, what approach they took, where they stepped in, and how they checked the result.

Because a person's knowledge and effort often show up in these details. To see them, we need to look a little beyond the first impression that forms the moment we hear the name of the tool they used.

As a recent graduate, I'm trying to adopt this mindset on the path I want to take. Mastering concepts brings ideas, and turning those ideas into reality takes technical skill. I believe that moving forward with this mindset will be a worthwhile investment in the future.