Enabling Non-Engineers to Contribute Code
Everyone is trying to optimize for how people can work in this new agentic era. Non-engineers also need to learn what features these harnesses offer for agents. The DevXP team at Slack supports numerous internal tools, but non-engineers aren't as familiar with things like a CLI. They haven't had the need to use a terminal or an IDE before, but now they're getting more comfortable, partly because we've worked really hard to enable them to that level. That's becoming a story for many companies, because now the roles have blurred.
There is a lot of tension from engineers that comes with enabling non-developers to contribute code. I think it's okay to talk about that out loud. The future is changing rapidly, and it's akin to a roller coaster — it can feel really fun, also a little scary, but it's happening.
Internal and External Tooling Converging
The DevXP team is collaborating with the product team more and more. The two sides used to be siloed; now they're converging. Anything we release externally, we test and dogfood it first.
We have product engineers now collaborating with DevXP engineers on what something looks like internally, and we want to hill-climb the experience with incremental improvements before it goes out into the world.
Sharing Custom Setups
Just dropping new models or features from AI companies with a note ‘Here’s some YouTube videos’ is not helpful at all for knowledge sharing.
What is more valuable is people sharing their customized setup. We would see, for example, someone on the growth product team really cooking with Claude, and we can see in our dashboards what Skills or MPCs they’re using, but we want them to share directly how they're using it.
People sharing their custom setups internally is very helpful, almost like word of mouth. When you see your peers adopting something, you get FOMO: Wow, I didn't know I could do it like this. That was something I did myself very early on, because you just don't know what you don't know. Most people think that whatever they're doing probably isn't that impressive. We really had to tell people not to think that way and just share.
Sharing is caring in this new world because so much is happening at an unprecedented rate, so everyone is continuously catching up. That's a new mental shift we're getting ourselves used to.
Building Slack’s Internal Dashboard
In January, when Opus 4.6 dropped, there was a huge shift in energy where people realized these models are really capable of doing quite a lot. I was a product engineer on the sidebar team at the time and starting to get really cooking with Claude and feeling overwhelmed by all the updates that teams were sharing across multiple channels. I wanted a central location for all of it in one place.
I started with a website, created an MVP, and shared it. Consolidation is very powerful — I think that's part of why Slack is so successful — and I was trying to consolidate all this information into one place.
That evolved to include not just the internal tools we had approval to use, the internal MCP servers we'd built, and external ones we recommended, but also metrics, so that everything was in one central place. That made it even more powerful, because people could tie usage of a specific plugin to actual numbers, since all our telemetry was being tracked in the dashboard too.
The dashboard is also the main way for people to discover tools. We also have integrations with Slackbot for our internal MCPs — Slackbot is basically your 24/7 AI assistant inside Slack, integrating with all our custom tools and features.
Sharing Over Tokenmaxxing
We do track usage and token spend in our dashboard, but we intentionally don't surface it prominently — it's one of the columns in a table, not something we highlight. We try to make the dashboard more about how we can help people see what’s being built internally, because that's more valuable information.
I don’t think it's helpful to focus on token spend because it's still only one part of the story. An engineer, especially now, will be doing a lot of work on alignment and cross-functional collaboration. Also, it's not helpful to the company to have a few power users with all the knowledge accumulated. Ideally they're sharing it as broadly as possible, so that everyone's bar is higher because of that.
Democratizing Tool-Building for Non-Engineers
Part of why the DevXP story is so powerful now is that we have non-engineers relying on us. A researcher at Slack, for example, now has the capacity to create a more bespoke dashboard than vendors offer, and the question we ask is: Do we have the right infrastructure that is accessible to a non-engineer for them to be able to deploy an app that is going to save the company a lot of time and money — or do we not yet? I think we are getting there, but we're not there yet.
There is still quite a lot of complexity for a non-engineer trying to deploy something internally. What we're trying to do is first simplify that complexity, then abstract it out completely with a UI layer — it's almost as if we're creating an internal version of Lovable for ourselves, which who knew was going to be something we'd end up building.
The Shift to Multiplayer Software Development
Historically, development has been really one-to-one: you open your IDE, you're creating a PR, you have a deep focus session, and you're the one iterating on your own. But implementation is rapidly becoming almost a solved problem, with models getting better; the benchmarks show they can now do 90% of what the average software engineer can do. Writing code is now really fast, cheap, and getting cheaper and more accurate.
The one-to-one is not necessarily the way it has to be anymore. It almost is a forcing mechanism: when execution is no longer as difficult, alignment and collaboration get actually more important.
If you're making many wrong decisions with what you're executing, that's wasting more time. But if you're thoughtfully planning things out and you have a lot of thoughtful decisions before you go into execution, then the execution becomes a lot easier, a lot more streamlined, a lot more accurate.
What we're seeing is the transformation into multiplayer: how does it look when humans and agents are really collaborating very closely together in an open space, and it's not just a one-to-one conversation?
Context Switching is the New Skill
A lot of the harnesses right now for agents are still one-to-one. But Slack was built for collaborating with other human beings — now we're seeing it evolve into something that's optimal for collaborating with agents as well. Dario Amodei said that context switching is going to become one of the most important human skills in this era.
It's very interesting how much we've shifted from "we need deep focus sessions" to "Actually, we will be context switching" — because now we can do three to five different work streams simultaneously in parallel with agents running in the background. That is a very fascinating mental shift for a lot of engineers, and I think some of us are still getting used to that new fundamental way of working that has evolved.
Rethinking Code Review
Since January, the number of PRs merged is over 2x. Obviously, that put a lot of strain on our internal infrastructure, so first we had to make sure that was better optimized. The bar has raised, we're outputting more than we used to because it's easier.
We are trying to figure out what the new code review process can look like when agents have made it so easy to create PRs. A lot of what we've done internally has been suggestions rather than forcing mechanisms. We'll suggest a lot: there are a couple of bugs here, this architecture could be better, you should probably add links to a preview, can you share more about the tests you ran.
What I have seen a lot of teams do is just say, If you see a bad PR, you have to be courageous enough to push back and say we can't accept this; it's not meeting the quality bar. That's a cultural shift, and it's good to have, but at the end of the day our tooling has to serve us as things evolve.
When a new hire comes in, they don't know the nuances of that culture yet, they have to learn it. So there are things internal tooling can solve for the culture. If we say 80% of new React files have to have 100% coverage, that's a forcing mechanism. It will actually force people to create more tests, which improves TDD in the culture. There are ways tools can enforce culture, and I think that's an interesting exploration.
Towards More Deterministic Frameworks
Our focus at Slack DevXP is now thinking about how multiplayer collaboration and the convergence of product with internal tooling teams look like. Enablement also takes up a lot of our time because the tools are shifting so quickly: keeping up with it, making sure the latest and greatest is shared, evangelizing to the right teams, hosting workshops. And rethinking the systems we currently have in place — the PR review experience, all the CLAUDE.md files we have. Are they actually doing what they should?
So much of this is non-deterministic, and we're trying to create more deterministic frameworks to make sure that what we're creating and what's being consumed by so many engineers is actually effective and doing what it's supposed to do.