Anthropic Uses Claude in Slack to Fix AI's

Here's the pattern I keep seeing: Company adopts AI coding tools. Engineers start shipping features 3x faster. Everyone celebrates the productivity gains. Then six months later, someone asks the obvious question: Why is our overall velocity barely different?

The answer is usually the same. The intelligence is trapped.

Your developers are working at machine speed, but your product manager is still writing PRDs the old way. Your support team is still waiting for engineers to explain how things work. Your marketing team is still filing tickets to get answers about when features shipped. The AI made one team faster, but the bottlenecks just moved somewhere else.

Brian Casel, who runs Builder Methods, recently highlighted something Anthropic—the company that makes Claude—wrote about their internal workflow. They're not just using Claude Code in terminals. They've integrated it into Slack so the entire organization can access codebase intelligence. It's a different model, and it surfaces a question worth asking: What happens when you treat your AI coding assistant as infrastructure instead of a developer perk?

The PRD Is Already Obsolete

The traditional feature development cycle goes something like this: Someone has an idea. They write it down, maybe in a product requirements document, maybe in Figma. There are meetings. Eventually an engineer gets assigned and starts building, interpreting the spec as best they can. Weeks pass. The feature ships, and it's kind of what people wanted but not quite.

This process has survived for decades because it was the best we could do. You can't hand a designer's mockup to a computer and get working code. Except now you can, which makes the whole dance look increasingly absurd.

According to Casel, here's what an Anthropic team member said about their process: "I don't really send memos or make mock-ups anymore. I just make Cloud Code prototypes." When someone has a feature idea, they tag Claude in Slack and get back an actual pull request—real code, built against the production codebase, using the team's existing components and patterns.

It's not necessarily production-ready code. But it's real enough that engineers can pull it down, see exactly how it behaves, and either ship it or rebuild it with full clarity about what they're building. The conversation shifts from "here's what I'm imagining" to "here's a working version—what needs to change?"

The efficiency gain is obvious. Less obvious is what this does to the power dynamics of product development. When anyone can generate a functional prototype, the question "is this idea worth engineering time?" becomes something you can answer in hours instead of weeks. You're not asking permission to explore; you're showing up with something concrete.

The Tax on Interruptions

Every organization has some version of this problem: Your support rep is on a call with a frustrated customer who's asking about an edge case. Your marketing writer needs to know when a feature shipped and why. Your sales rep just got a technical question and the prospect is evaluating competitors.

The answer lives somewhere in the codebase, in commit messages, in documentation that may or may not be current. But the person who needs the answer can't access it directly. So they ping an engineer. And they wait.

Meanwhile, the engineer was deep in something that required actual thought—refactoring business logic, architecting a new feature—and now they're context-switching to answer a question they've already answered twice this week.

Casel points to the Anthropic approach: Non-technical teams ask Claude directly in Slack. The system can read the codebase, including git history, and answer questions like "how does this feature handle X?" or "when did we ship this and who built it?" Support gets answers without waiting. Marketing hits deadlines. Sales follows up while conversations are warm. Engineers stay focused.

This is the part where someone usually objects that AI can't truly understand context, might hallucinate answers, could give misleading information. All true. But compared to what? Compared to an engineer who's annoyed at being interrupted, half-remembers the implementation, and gives a quick answer that's 80% right but missing the crucial 20%? The baseline we're comparing against isn't perfect either.

The interesting question isn't whether the AI is flawless. It's whether giving teams imperfect-but-instant access to codebase knowledge is better than the current system of playing telephone through engineering. My guess, based on 25 years of watching companies operate: probably yes.

When Your Data Talks to Your Code

The third piece Casel highlights is the one that caught my attention most. Anthropic apparently connects Claude to their analytics and event logs, which means people can ask questions that span code and data.

"What's the completion rate on the new onboarding flow?" The AI knows what events exist because it can read the code. Then it queries the data directly.

This solves a problem I've seen kill momentum at every company I've worked at: the two-step question. You want to know something that requires both engineering context (what are we tracking?) and data analysis (what do the numbers show?). So you ask an engineer what event to look for, then ask a data person to run the query, then wait for both of them to have time, then hope the answer you get back actually addresses your original question.

With code and data connected, your product lead can ask directly. Your ops team can connect code changes to business outcomes without guessing. Your CEO can get clarity without scheduling a meeting.

The obvious concern here is security and access control. You probably don't want everyone in the company querying production data or reading every line of code. Fair. But that's an implementation detail, not a conceptual problem. The pattern—making codebase intelligence accessible to the people who need it—doesn't require giving everyone root access.

The Part Nobody's Talking About

What strikes me about this whole approach is what it says about where the actual value is in AI coding tools. Everyone's focused on the individual productivity gains—developers shipping features faster—because that's easy to measure and exciting to talk about.

But the bigger opportunity might be organizational: turning your codebase from a technical asset that only engineers can access into institutional knowledge that powers your entire company.

That's not a new idea, by the way. We've been trying to do this for decades with documentation, wikis, internal tools, knowledge bases. It never quite worked because maintaining documentation is a tax nobody wants to pay, and it goes stale immediately.

What's different now is that the intelligence can be extracted directly from the code itself. Not from what someone wrote about the code six months ago, but from what the code actually does right now. The documentation is the codebase, and the AI is the interface.

Will this work? I don't know. I've seen enough collaboration tools promised to "break down silos" and "democratize access" to be skeptical by default. The technology might be new, but organizational dysfunction is eternal.

But here's what I'm watching for: Companies where non-technical teams start moving at technical speeds. Where the time from "customer complaint" to "we've identified the root cause" drops from days to minutes. Where product decisions are based on actual codebase constraints instead of vibes.

If that starts happening at scale, then maybe we're looking at something that actually changes how software companies operate. Not because the AI is magic, but because it finally makes the intelligence locked inside your codebase available to everyone who needs it.

—Mike Sullivan is Buzzrag's technology correspondent and has seen every productivity tool promise to revolutionize collaboration since Lotus Notes.