AI Best Practices for the Workplace

A common problem I see in AI transformation discourse is the obsession with tool usage above all else.

Are you using Claude Code / Cowork / Design yet? Codex? Some new hype-named skill like grill-me, caveman, or superpowers? What’s your token usage? Are you AI-native?

A lot of these conversations push usage as the goal without much guidance on effectiveness, conventions, or what “good” actually looks like. The result is real workplace friction.

One version of that friction is “workslop” (HBR article). AI-generated output that looks polished enough to pass along, but still requires someone else to review, correct, restructure, or fully redo it. Instead of making the team faster, it quietly shifts the burden onto the people most capable of catching the problems.

That's where the 10x productivity narrative starts to break down.

When weaker performers use generative AI poorly, they do not magically become 10x operators. They can just as easily produce 10x more vague analysis, oversized pull requests, half-checked summaries, and deceptively confident output. Then top performers feel responsible for absorbing that slop before it reaches customers, leadership, or production.

Now the team has not eliminated work. It has redistributed it.

There are a lot of angles to this problem, and one common response from the AI crowd is “just use AI to review it.” I think there's some merit to that, but it's also incomplete. AI review can help catch issues faster, but it does not replace accountability, judgment, or shared team standards.

What teams need is a set of norms for responsible AI usage in the workplace. Not to slow adoption down, but to make sure adoption actually improves the work instead of flooding the organization with faster, shinier garbage.

That redistribution isn't harmless. It creates a real operating tax:

  • Trust erodes when teammates feel like they're reviewing unvetted AI output instead of collaborating with another professional.
  • Capacity gets burned on cleanup. BetterUp Labs and Stanford found 40% of workers have encountered workslop, costing nearly two hours of rework per instance (Study link).
  • Top performers pay first. The people best equipped to catch the problems become the backstop for everyone else’s slop. And the promised efficiency gains rarely come back as breathing room. They get absorbed into higher output expectations, a pattern researchers are calling “workflation.” (article)

The fix isn't another tool mandate. It's better norms and practice. Responsible AI usage needs norms for what individuals own, how teams collaborate, and what leaders choose to reward.

Individual Responsibility

  • Ownership — you ship it, you own it
  • Formatting — format for the medium before you share
  • Bloat — trim output to what your audience actually needs
  • Verify — read it before you forward it
  • Disclosure — label raw AI output, refine your own freely
  • Receiving AI Output — ask questions, don't absorb review burden silently

Team Practices

Org / Leadership Strategy

Individual

Ownership

First and foremost it needs to be understood that the user of AI is always responsible for the output they use. If you ship code generated by AI, it's your name on it, not Claude's. This assumption helps to drive home some of the accountability required, so poor usage is attributed to the owner.

Formatting

Never share unformatted or misformatted text from an AI tool. This is the fastest way to propagate workslop and lose coworker trust.

When I see a massive chunk of poorly formatted Markdown in Slack it indicates to me that my time is not worth the 10 cents worth of tokens it takes to ask AI to format for your medium or research a skill to help you do so.

Invest some time in finding or creating a few skills for copying into your preferred medium of choice. Slack, Confluence, email, all have some formatting idiosyncrasies that you need to massage into and it's your responsibility as the sharer to do so.

Also consider alternative mediums to share. Sometimes a massive debug session or data report isn't effectively communicated through a Slack, convert it to a Confluence page or even ask AI to write it to an HTML file. These have advanced visualization capabilities baked in and AI is very good at writing them from scratch.

If AI doesn't get you there then take the time to do so manually, the reputational savings outweigh the time savings.

Bloat

Writing text is cheap now. Your teammate's time is not. AI tools are often biased toward generating more than you need. Whether that comes from model behavior, product defaults, or token economics, the result is the same. It's your responsibility to make the output consumable.

Simple words like "brief", "succinct", and "concise" can all go a long way to restrain the output and help you tweak it to something actually readable by your audience.

This applies to scope too, not just length. AI makes it easy to generate a lot in a single pass, but that speed isn't a reason to ship oversized PRs or deliverables that no one can meaningfully engage with. The scoping discipline that applied to handwritten work still applies here. A reviewer who can't realistically get through a 2,000-line PR isn't reviewing it, they're approving it, and that's workslop one step downstream.

Verify

The minimum bar for distributing AI content is to actually read it, or test the process that generates it thoroughly. Stats and figures should come from tools and integrations, not the model spitting out values. AI is very good at analyzing large amounts of information but it will just as easily make up values without some checks and guidance. It's your responsibility to make sure you have some sort of smell test before forwarding content on.

Links are worth spot-checking too. A citation that 404s or points to an article that doesn't say what you claim is just as bad as no citation. If a stat or source matters enough to include, it matters enough to open the link.

Disclosure vs Non-Disclosure

Always disclose if you're copying raw AI output to share with colleagues. It baselines with everyone that you're sharing something you haven't had the capacity to thoroughly vet but you think is value add.

I often preface text blocks with the robot emoji (🤖) or a "Claude Dump" to level-set where it's coming from. This indicates respect for your peers and prevents them from assuming it hasn't been vetted and it reflecting poorly on you when there are some inaccuracies included.

Beyond courtesy, this actually changes how people engage with what you send. A study of 14,300 GitHub commits found explicitly labeling AI-assisted work triggered 23% more review questions and comments (arXiv). The label signals "second look required", which is exactly the right response from reviewers.

Some AI output is also unmistakable for what it is. Em-dashes in every other sentence, every thought broken into headers and sub-bullets, colons where a comma would do, and a relentlessly helpful tone no one actually writes in naturally. Passing that off as your own isn't just bad etiquette, it's a credibility risk. Most people can spot it, and getting caught reads worse than labeling it upfront would have.

If you're refining a thought or text that you yourself wrote I don't think you're obligated to disclose the usage. You're actually using AI to improve the work output in that case to ease your recipients burden in that case.

Receiving AI Output

The norms above cover what to do as the sender, but you'll inevitably be on the receiving end too. A few principles worth holding:

Ask clarifying questions freely. If something reads like irresponsible AI output, a quick "did you check this?" is entirely reasonable, and the disclosure norm above is exactly what makes that conversation easy to have. The label removes the social friction.

Don't absorb the review burden silently. Quietly spending an hour cleaning up someone else's workslop is how the pattern perpetuates. Surface it once, offer the context on why it matters, and move on. The goal is a higher floor across the team, not punishing individuals.

Team

Prompt Visibility

Share your prompts! It allows teams to collaborate and refine AI inputs together and catch issues that individuals often miss. Natural language can be finicky and there's a wide range of interpretation in communication and writing styles. By increasing visibility to raw inputs you'll be able to refine core communication skills required for your business processes.

Context Visibility

AI responses are heavily dependent on what context you provide as baseline. If you identify a common gotcha for your workflow and provide the context instruction as rules / memory / or system instructions that's worth sharing. Over time the team should get a rich corpus of common info to raise the baseline for all members using AI.

A good next step once you've built that corpus is to consolidate the most broadly applicable pieces into a shared team context document. Something your team can drop into new AI projects, system prompts, or config files to give everyone a consistent starting point. If your team's prompts are all starting from scratch with different framing, you'll get inconsistent outputs across people on the same tasks. A shared context doc closes that gap and gives you a single place to improve rather than everyone independently rediscovering the same fixes.

Communication and Distribution

Creating central channels to foster knowledge sharing, like #ai-learnings Slack channels, helps surface and share effective usage patterns. Doing it in the open allows the good patterns to trickle out from the power users and gives a forum to refine any that aren't fully up to par.

In parallel you need a mechanism to distribute the best in class skills and processes outlined for repeat usage. The bar should be low to start here but you'll need to tune your review process over time as adoption and dependency on core flows grow. A GitHub repo is a good start but maybe a Google Drive or similar cloud store works better for your team starting out. Either way it needs to be communicated on how to upload and download effectively.

Automated Messages

This one is a bit trickier as I think there's some merit to automating common messages, alerts, and processes through AI. I think the key is to ensure the messages are always accurate and contain continuous value.

If your scheduled post hits daily, follows the same format, and gets no reaction, it's noise, not value. Be open to tweaking or removing these posts over time as you find gaps. Place a high burden on yourself to vet the process outputs before blasting them to the masses.

Org / Leadership

Gamified Metrics

Gamified incentives, like token leaderboards, are a sure-fire way to yield poor usage. Pushing for AI without an accompanying standard to reference will result in widespread workslop.

The data backs this up. Teams using AI coding assistants showed a 9% increase in bugs per developer and a 154% increase in average PR size with no improvement in delivery velocity (Faros AI). Volume went up, quality went down. If your only metric is usage you'll never see that tradeoff coming.

When Not to Use AI

A peer-reviewed study found teams with unequal AI access (some members using it, some not) outperformed teams where everyone had full access (NIH/PMC). The cognitive diversity from some members bringing unassisted judgment turns out to be an asset, not a gap to close.

It's worth building into your team norms which roles and tasks benefit from AI, and which ones should stay human. Not because AI can't help, but because the mix might already be working better than a full rollout would.

Showcase Discerningly

When leaders highlight a project or AI use case it holds a lot of weight. Few things kill AI momentum faster than championing a half-baked demo to your team. It signals you can't tell the difference between something that looks good on first pass and something that's actually ready to ship.

The tricky part is that AI collapses the time to demo. A prototype that would have taken weeks now takes hours, which sounds great until you realize demos were never a reliable signal of quality to begin with. What AI does is make the easy part even easier. Getting to a polished, reliable, production-ready product still requires the same attention it always did, and the demo is actively working against your ability to see that.

Require more than a demo before you put your name on something. Dig into edge cases, ask what breaks, use it yourself on a real workflow. The reputational cost of backing something that falls apart on contact is higher than taking a few extra days to properly evaluate it.

Admit Defeat

Failures are just as worth surfacing as wins. ICs know when an AI implementation isn't delivering because they're the ones using it every day. If your narrative is uncompromisingly positive you'll lose credibility with the people you most need to trust your judgment on what's actually worth pursuing.

It also makes it harder to cut losses. It's easy to keep pouring resources into AI efforts in the name of being "AI-native" when the underlying work isn't generating real value. Like any other tool investment, some efforts are worth doubling down on and some are worth cutting loose.

The good news is AI rewards this mentality more than most. Rapid prototyping means a clean restart with lessons learned is often faster than trying to salvage something brittle. The hard part is the admission itself, and being honest about what actually went wrong.

References