On one sunny morning on the 8th of october my co-founder @igorzij invited a strange app into our slack, it was named @calvin. He randomly started chatting to it and interrogating it. I looked at the chat puzzled.
The previous week we had been trying to get a “software factory” going so that we can all move to coding in the cloud. We tried many different tools but none of them completely caught on to the team
Changing the way the team writes code is a difficult task, it needs buy in from the team, as in they need to be genuinely excited about using a new tool to get the job done. We had previously tried bringing in devin but it never really caught on. I used it a bit through the web interface, I fired alot of sessions on it for overnight and so on - I synced all the sessions to my slack but it didn’t really catch on.
Over the next week or two I found that my excitement of using it vanished. I was overwhelmed with sessions that never got reviewed, these older sessions were outdated by newer PRs that then conflicted. It wasn’t just a matter of rebasing the old branches - actually the assumptions made in the older sessions no longer applied. So I found that I was stuck in a limbo of feeling like I was getting a lot done when in reality I was launching a lot of sessions that never got done, which might be partially due to this:
At that point I realised that if you are delegating async work to agents you better close the loop or close the session, otherwise the most scarce resource (human attention) gets swamped by switching too much. The only way for async to work is if you have closed the entire verification loop and automatically push to main right away. But a lot of us are not there yet - we still prefer to be in the loop for the "go live".
Anyway, so on that 8th October morning Igor asked the team for a quick chat. After we got on the call he was too excited and he showed us the @ calvin bot - "look guys, its so fast i never even have to leave the chat" he said.
And indeed it was, it felt almost instant to respond and share feedback. Even when it was working and had its charming way of showing progress with _just_ the right amount of detail.
Some more context about why we chose to go down this path: earlier this year we didn’t really have preferences on the tooling used, every individual was using the tools which they see fit. What happened as a result was pretty annoying because we would ship features as PRs. what’s interesting is that a lot of the decisions, riffing and explorations that lead to this PR are often lost in your chat with the agent. At that point I realised how valuable it is to share the chat context with the team. Esentially shifting left from the PR is to be shared, because that’s where all the valuable knowledge lies
So on that day we decided to switch all of our feature and fix work to slack, and we rebranded our app to be @ computer, a star trek theme. Looking back at october, here are the results team-wide:
I personally have not touched my local codex in october except to do some browser controlled task in my logged in browser session.
You would also notice that it extended beyond coding to other work such as researching different methods, automations, data analysis and some GTM work. The biggest flip for me personally was that you rarely have to wait for a response, so context witching rarely happens when I am in a thread with @ computer:
The way we work
We have our code split across 3 repos, we also have a “knowledge” repo where all the agents planning work resides. For any work beyond a small fix we usually ask the agent to write a detailed plan spec and push it to the knowledge repo, hence future sessions can see it
Once the plan is completed the agent can implement the piece and create necessary pull requests, it writes the basic tests and it can validate it in a preview environment if needed
Now the cool part after moving our sessions to slack is that it instantly became multiplayer. If you wanted to loop in another team member on a decision previously you had to share agent context from local paste it in there get their thoughts and back. But now all you have to do is @ them to get their thoughts, or to just share results:
In this example Utpal was doing some work on site discoverability. And the cool part is that he doesn’t need to explain what was done, its all there in the thread
It’s also cooler to have a shared space for context because if a feature has multiple individuals working on it, you can start a thread and the second person goes right in to continue the work. Or if someone starts a quick thread but abandons it another team member can jump right in and carry on the work.
Furthermore if a customer complains about a bug in slack its easy to forward request to a channel tag @ computer and get to work with it.
In the beginning we had a unified #dev channel for all work where each feature work is a thread. However we then started to split them into ux, features, bugs and separate channels for each. Admittedly
What still needs improving:
The problems we faced when it comes to doing everything in slack is that it is still difficult to see what was done at a glance, so the ui isn’t great for that. There is “agents & tools” tab in slack but I do often find myself lost amidst the threads if there is more than a handful
It would be great if there was a way to know at a glance what is still waiting action from me and what are the closed loops which I can hide, so that my attention loop is better managed
Try it
If you are embarking on this journey within your team and looking for where to get started try opencomputer.dev, its the fastest coding agent which was built to be consumed in slack.