Most AI at work is bullshit

Most AI work inside companies is bullshit.

It's not because AI is bad, or that people are lazy. It's not even really that the tools are overhyped, though, okay, a lot of them are. Most AI at work is bullshit because companies are trying to adopt AI without changing how work is managed.

That distinction matters. A lot of companies think they are becoming AI-first because more employees are using AI tools. But AI usage is not transformation.

People inside your company are rewriting emails faster. People are summarizing meetings. Someone builds a little demo. Someone creates a prompt library. Someone posts in Slack that they used Claude to think through a problem. For a few weeks, the company really feels like it is moving.

But the work itself often stays the same.

This is the strange part about AI adoption. AI is supposedly the thing that will change everything, yet most companies use it to preserve the existing system. The same workflows, meetings, dashboards, job descriptions; the same incentives and very similar results. The only difference is that now some of the work is slightly faster, slightly more automated, and slightly harder to evaluate.

That’s how you get bullshit AI work: work that creates the feeling of progress without creating much actual value.

The way I look at it, there are a few levels of bullshit AI at work, and they largely go along with whatever the level of AI adoption is at your company.

AI adoption stages

A company with no real AI initiative has one kind of bullshit. A company where leadership tells everyone to “use AI” has another. A company where everyone is vibe coding has another. And the most advanced companies eventually run into a harder truth: this was never mainly about tools. It was about change management.

BS 1: The vague AI push

The first kind of bullshit is the vague AI push.

This is when leadership announces that everyone should use AI more. The message usually sounds right: "We need to become AI-first. We need to automate repetitive work. We need to free people up for more strategic work. We need everyone to start experimenting with AI."

None of this is wrong. The problem is that it's incomplete.

What happens after the announcement? Usually, not much. No dedicated time. No clear goals, or budget. No operating rhythm. No explanation of what good looks like. No change to team priorities. Just a message, some emojis, maybe a new Slack channel, and a general feeling that everyone is now expected to figure it out by themselves.

The company thinks it has started becoming AI-first. In reality, it sent a Slack message. The expectations and pressure are high, the directions are low.

I don't actually know where I took this from. Sorry.

This is not an AI strategy. It's a wish.

If leadership wants AI to become real, they have to make it real in the calendar, the budget, and the operating system of the company. At Omnisend, we eventually created an initiative called AI as a Habit. The idea was simple: AI was not something people were supposed to squeeze into the gaps between meetings. It was part of the job.

We allocated a percentage of people’s time to working with AI. We carved it into their planning; created actual space for them to explore, learn, and apply AI. This matters because time is the most honest signal a company can send. If something is important, it gets time. If it gets no dedicated time, it is not important. It's just decoration.

Omnisend's "AI as a Habit" initiative

We also created monthly AI Days.

On the first Friday of every month, people cleared their calendars and focused on AI-related improvements. Most meetings were cancelled. Some of the day was education, some of it was experimentation, and some of it was teams sitting together and asking what painful part of their work could be improved.

The exact format dependds on what your company or your team can allow, and honestly it matters less than the signal. AI became real work.

And this is the thing leadership often misses: people do not change how they work because leadership says “please innovate.” They change when the system around them changes. If you tell people AI is important but give them no time to work on it, they will understand the real message: AI is important, but not as important as everything already on your calendar.

So yes, at the beginning, you probably have to force the time a little bit. Not in a creepy way. But in the sense that you put it on the calendar and say: this is the time. Clear your schedule. Work on this. No opt-outs.

Otherwise, you're asking for it to happen organically, which means it will happen very slowly, which means it probably will not happen at all.

BS 2: Productivity theater

The second kind of bullshit is productivity theater.

This usually happens after people have started using AI for small individual tasks. They polish emails, summarize documents, rewrite Slack messages, use meeting note tools. Draft posts. Turn messy notes into something presentable.

Some of this is pretty useful. I use AI for a lot of these things myself. But the thing is that individual productivity is a good starting point, but really a bad destination.

The problem is that companies often mistake individual activity for organizational improvement. Someone says they saved 30 minutes writing an email. Great. But did the team get better? Did the customer experience improve? Did the reply rate go up? Did the sales cycle shorten? Did the campaign perform better? Did the decision improve?

Often, no one knows. In fact, an MIT study [pdf] showed that 95% of enterprise organizations, that had invested $30-$40 billion in AI saw zero return.

The true state of AI?

This is where self-reported productivity becomes dangerous. People are genuinely bad at estimating time saved. They are even worse at estimating impact. And when leadership asks for AI success stories, people learn to tell stories that sound like success.

“I used AI to do this faster” sounds good. But faster is not always better. Sometimes it's just faster.

A person can write emails faster while the team’s positive reply rate stays exactly the same. A marketer can produce more variations while conversion does not move. A manager can summarize meetings faster while the same decisions still get delayed.

The outputs improved, but the outcomes did not. That is productivity theater.

The fix is to reward impact, not AI usage. At Omnisend, we introduced an AI Salary Bump. The idea was not to reward people for using AI (creating the wrong incentive). The idea was to reward people who used AI to make their work, or their team’s work, more efficient, more impactful, and adopted by others.

The Omnisend AI Salary Bump

Efficient means it saves time or money. Impactful means the work actually gets better. Adopted means it survives outside your own personal workflow.

If you use AI to save yourself 20 minutes once, good for you. If you use AI to change how your team works every week, that's different. The question should not be: did you use AI? The question should be: how did you use AI to actually improve your work?

There is also a cultural point here. This was not framed as a punishment for people who do not use AI. That distinction matters. Because the moment AI adoption becomes a compliance exercise, people will perform compliance. They will use AI because someone asked them to use AI. They will produce AI activity because activity is what gets noticed.

But if AI becomes a way to create and reward actual impact, serious people will treat it seriously.

BS 3: Shiny project mode

The third kind of bullshit is shiny project mode.

This is what happens when companies move from individual productivity to building things. Teams try twenty tools. Someone makes a demo. Someone vibe codes a small app. Someone else builds a workflow. By Friday afternoon there is something that kind of works, and everyone feels the future has arrived.

Then Monday comes, and everyone goes back to their real work.

The demo sits there. No one owns it. No one maintains it. No one measures whether it works. No one adopts it. The next AI Day comes around and the cycle repeats.

Build. Abandon. Repeat.

This stage is common because building with AI feels like progress. It gives people something to show. It creates the feeling of momentum. And to be fair, experimentation is necessary. People need to play with tools before they can understand them. They need to try things that don’t work; they need that messy phase.

But experimentation only matters if it compounds. Otherwise it is just expensive curiosity.

The fix is to move from projects to products.

The project vs product mindset

A project has a demo. A product has users. A project has an output. A product has an outcome. A project can be abandoned after the presentation. A product needs ownership, maintenance, adoption, feedback, and some way of knowing whether it's working.

This was one of the biggest shifts for us. We moved away from “what can we build during AI Day?” toward “which workflows should we improve this quarter?”

That sounds less exciting, because it is. Real AI work becomes boring very quickly. But boring is usually where the value is.

A prompt that helps someone write an email faster is a project. A system that increases positive response rates from 2% to 4% is closer to a product. The difference is not in the technology, but rather in the expectation.

One -- the project -- is about creating something. The other -- the product -- is about changing something.

That’s why we eventually moved toward decentralized AI time. No more one-size-fits-all company-wide AI Days on the first Friday of each month. Each department could decide when its AI Days, half-days, or working sessions made sense. More importantly, departments started focusing on core workflows on a quarterly basis, with KPIs tied to outcomes.

This is where it becomes less “AI event” and more operating model. It’s not about the cool thing you built on Friday. It’s about whether anyone is still using it three weeks later.

BS 4: Everyone should be vibe coding

The fourth kind of bullshit is the company science fair era.

This is where everyone is encouraged to build. Everyone gets introduced to tools like Lovable, v0, Cursor, Replit, Claude Code, Hostinger Horizons, or whatever the current favorite is. Non-technical teams start vibe coding apps. People build little dashboards, internal tools, landing pages, Chrome extensions, automations, forms, workflow helpers.

Again, some of this is good. Vibe coding can be genuinely powerful. I am not anti-vibe coding. I'm a vibe coder myself; I use these tools regularly, and they have changed how I work.

But the trap is assuming that because everyone can build, everyone should build.

The reality is that AI democratized access. It didn't democratize outcomes.

That distinction matters. More people can now create software-like things. But that does not mean everyone has the patience, judgment, taste, technical intuition, or interest to turn those things into something useful.

A non-technical person can spend three days debugging a login issue in a vibe-coded app. Is that empowering? Maybe. Is it the best use of their time? Maybe not. This is the question companies need to ask much more often:

"What is the best use of this person’s time?"

Not “can they build this with AI?” Increasingly, the answer will be yes. The better question is: should they?

Sometimes the right model is not “everyone becomes a builder.” Sometimes the right model is that domain expert becomes the product thinker, a skilled builder is the execution, and AI is the acceleration.

The domain expert understands the problem. They know the workflow. They know what good looks like. They know what would actually save time or improve quality. But that does not mean they should be the person fighting with deployment, databases, permissions, authentication, or some weird bug in a generated codebase.

Because let’s be honest, this is where vibe coding can get weird. You build something that works on your laptop. Great. Now what? Where does it live? Who owns it? Is the data safe? What happens when it breaks? Who fixes it when the model changes or the tool updates or the person who built it goes on vacation?

These are not reasons to avoid vibe coding. They are reasons to be honest about what stage the thing is actually in.

The goal is not to turn everyone into engineers. The goal is to make sure good ideas do not die because the wrong person was forced to build them.

This is where companies need better internal systems. Maybe that means an AI job board, where non-technical teams post problems and skilled builders help execute them. Maybe it means dedicated AI builders embedded across teams. Maybe it means buying third-party tools before trying to recreate them internally. Maybe it means no-code tools. Maybe it means actual engineers.

An AI job board

The answer depends on the company. But the principle is the same: do not confuse access with leverage.

Vibe coding by itself is not the trap. Forced vibe coding is the trap.

BS 5: Everyone’s gonna make it

The final kind of bullshit is the most uncomfortable one. It is the belief that everyone will eventually adapt.

Leadership assumes that if people get enough training, prompts, workshops, tools, encouragement, budget, and time, they will all become AI-native eventually.

Some will. Some will not.

This is where AI adoption stops being a tooling problem and becomes a change management problem. AI does not just ask people to learn a new tool. It asks them to question the system that made them successful.

Some people are optimized for the old system.

They built their careers on a specific way of working. They know how decisions get made. They know how to look productive. They know how to win in meetings. They know how to move information around. They know how to create the documents, dashboards, updates, and processes that the old system rewarded.

Then AI arrives and quietly asks: why does any of this need to exist?

That is not a comfortable question. A lot of resistance to AI is not fear of technology. It is loyalty to a version of work people understand well.

This is why treating AI adoption as training is not enough. Training assumes the main problem is knowledge. Teach people the tool and they will use it. But often the real problem is identity. People are being asked to become a different kind of worker.

And that requires different management.

Leaders should not expect equal adoption. Some people will run toward AI. Some will use it pragmatically. Some will pretend. Some will resist. Some will not know why they are resisting. And this is difficult because the resistance will not always look like resistance. Sometimes it will look like “I’m too busy.” Sometimes it will look like “this tool isn’t good enough yet.” Sometimes it will look like “we need a policy first.” Sometimes those things will even be true. But sometimes they will also be a way to protect the old system.

Leaders need to create different paths. Not everyone needs to vibe code. Not everyone needs to build agents. Not everyone needs to automate workflows. But everyone needs to understand how their role becomes more valuable in an AI-enabled company.

That means making expectations explicit. If AI-assisted research is now the default, say that. If manual reporting should decrease by 50%, say that. If a sales team is now expected to use AI for follow-ups, say that. If a role requires judgment more than output, say that too.

The worst thing leaders can do is keep the old job descriptions while quietly expecting new behavior.

Eventually, some roles will change. Some will shrink, while others will disappear. Some will become more valuable. Pretending otherwise is another kind of theater. You cannot move into a new system while still rewarding all the rules of the old one.

If you are trying to build an AI-native company, you have to be honest about what that means. It affects hiring. It affects role expectations. It affects promotion. It affects compensation. It affects who gets recognized. It affects who struggles.

This is not a technology issue. It's a human issue. Which means it is a leadership issue.

The real work

Most companies ask the wrong AI question. They ask: "How can we use AI?"

That question creates bullshit. It creates random tools, vague initiatives, prompt libraries, demos, productivity claims, and employees trying to make their normal jobs look AI-native.

The better question is: "What work should change?" What should become cheaper, faster, better, or unnecessary? Once you ask that, AI becomes less mystical. It becomes part of work design.

That is the real shift. AI adoption is not about getting everyone to use AI. It is about redesigning work around what AI makes possible.

That means starting with workflows, not tools. Bad question: how can we use AI? Better question: what work should become cheaper, faster, better, or unnecessary?

It means giving people dedicated time instead of telling them to experiment when they are already busy. Bad instruction: use AI when you have time. Better instruction: this is part of your job.

It means funding outcomes, not usage. Bad metric: how many people used AI? Better metric: which workflow improved?

It means asking whether vibe coding is actually the best use of someone’s time. Bad assumption: everyone should build with AI. Better question: what is the best use of this person’s time?

And it means managing role change, not just tool adoption. Bad assumption: everyone will adapt. Better question: how does this role stay valuable when the old system changes?

The companies that win with AI will not be the ones where everyone uses AI the most. They will be the ones where work is redesigned and everyone understands where they still create value. That is harder than buying tools. It is also much more useful.

Because AI will not fix work that does not matter. It will just help you do more of it.