Slack is the new IDE

By November 2028, there will be more PRs shipped from Slack than from all other places combined. This is just a fact, clear as day, even though today most teams are using other tools as their daily drivers.

The reason is not that Slack is somehow the best IDE for software engineering today. It may well become one though; Salesforce leadership seems to have embraced Slack as their AI flagship. But even if they don’t change Slack much, it is inevitable.

Work already lives in Slack

The main reason Slack will become the de-facto standard for shipping changes to production is that it is already there. Work happens in Slack. All the context is there. Important discussions and decisions happen in countless channels and threads. It’s the de-facto context hub. Alongside Notion perhaps, but only a fraction actually gets there.

Many teams - most, if we are being honest - are not great at maintaining their knowledge systems. To put something in Notion (oh and remember Confluence?) requires conscious effort and oftentimes simply doesn’t happen. Documentation is a good practice; organisations that are mature enough put them in place and follow diligently - but still, inevitably, the “wiki knowledge” is lagging the actual up-to-date context; if it is captured anywhere at all, it’s likely in Slack.

Human attention management

There is another, deeper reason that makes Slack the new IDE. And it is the same reason that made Slack popular in the first place. What was it so special about Slack at the time when it exploded in popularity? There was HipChat and many other team chat apps. Why people started switching to Slack in droves - so much so that today there’s only Slack and Teams left?

My theory is that the creators of Slack figured something fundamental about presentation of disjointed flows of information that made it the obviously superior option as soon as you try it. It is something that HipChat lacked and Teams lacks to this day - making the insanely high volume of information flowing in all directions manageable somehow. With channels and threads and stars and pins and customisable notifications it allowed organisations to fine-tune their information flows to reduce the signal to noise ratio for every team member.

Now, is keeping track of all the agents you care about that different from keeping track of what’s happening in your corner of the organisation? With agents everyone is a manager, and forced to multi-task, at least for now until AI-first workflows get specialised enough to form the new layer of software. So the problem of reducing noise and managing users’ attention span are by and large the same. So paradoxically, the most human-centric piece of software - the one we use to talk to each other - also happens to be the perfect surface for interacting with agents.

Building together, aka “multiplayer”

If you’ve been in the software industry long enough, then you know that one of the most accurate ways to estimate how long a large project is going to take is to ignore the scope of work altogether - as in literally, it does not matter what is being delivered - and simply count the number of people involved. It is going to be roughly proportionate to N^2. Different organisations move at different speed, so add a constant factor; but having an internal reference, this method is shockingly accurate.

The reason this seemingly ridiculous method is so accurate is that in projects that involve significant number of people, communication overhead dwarfs all other efforts. Most time is spent simply on passing information from one head to another. This is why The Mythical Man-month had to be written; and also the reason why creating the then-new Agile / Scrum way of building software was necessary. The hardest part of knowledge work at scale, it turns out, is coordination, not the work itself. This is also why high-performing teams tend to be flat, with individuals owning large chunks of businesses and products end-to-end as opposed to granular specialisation.

What does it have to do with Slack, one might ask?

Before AI, software was built piece by piece, by individual engineers owning each piece, and then - devops maturity permitting - shipped frequently into development and / or preview environments and hopefully just as quickly into production. Which in itself was a massive improvement over old-school way of shipping in big releases; I won’t go into detail as to why - it’s been a standard practice since late 2000s, “shift left”, short feedback loops, all that stuff.

But one part of the shipping process remained somewhat arcane - the pull request. Until the engineer raises a PR, no one knows what she is actually building. Hopefully it’s the right thing; but maybe not. Another best practice is to ship in tiny atomic PRs, but that is not always feasible, especially for changes that are non-trivial and affect multiple subsystems. So it was and still is very common for an engineer to spend entire day or perhaps even multiple days working on a change, only to learn after raising the PR that the way they thought of it was completely wrong. This is the opposite of “shift left” and tight feedback loops.

Now imagine if building happens in public channels, for everyone to see. You don’t even need a PR as such - anyone can jump in and quickly glance at the thread and get a sense of what is being built, what product or business tradeoffs does it imply, and so on. And where would these threads live? Perhaps in some kind of a “social IDE”? Where you would have channels, and threads, and pins… yeah. Exactly like Slack. The one we already have!