500 people vibe-coded for 30 days. I was one of them. - Sanja Grbic, Automattic

summarized

TLDR

A 30-day experiment at Automattic called Radical Speed Month allowed 500 people to build and ship projects with AI tools, shifting the speaker from designer to design engineer. The talk details three projects—a board game session manager, a design system status tracker, and an iOS chat for WooCommerce—and the system-wide impact of giving teams autonomy and access to AI.

Key points

  • The experiment gave two-person teams full autonomy to build and ship projects for 30 days, with about 500 people participating.
  • The first project was a board game session manager built in 2 hours with a mixed-skill team, highlighting the importance of engineers enabling others.
  • The second project was a design system status tracker that the speaker built solo in 2.5 weeks, marking her transition from designer to design engineer.
  • The third project was an iOS chat for WooCommerce merchants built in 6 days with a fellow designer, demonstrating a complete shift in process from Figma-first to code-first.
  • AI tools like Claude Code and Figma were used alongside internal resources such as Context AC MCP server and company documentation.
  • Engineers need to become enablers and teachers as more non-engineers start working in code.
  • Giving people agency, space for experimentation, and access to tools is crucial for unlocking speed in large organizations.
  • The speaker's process shifted from starting in Figma to building prototypes directly in code, then using Figma only for visual fine-tuning.

Tools mentioned

Techniques

  • vibe-coding
  • pair programming with AI
  • proof of concept development
  • design system status tracking
  • building prototypes directly in code
  • using AI for research and planning
  • asynchronous collaboration with AI tools
Transcript (captions)
Hi there. Welcome to my talk. My name is Sanja and today I'm going to share with you an experiment we did at our company that's somewhat unusual and very exciting. It was a one-month initiative called radical speed month where two-person teams were given full autonomy to build and ship projects. I built three projects during this time. I will walk you through them and we'll talk about the outcomes and learnings for myself as a designer as well as the system-wide impact this experiment had. I'll tell you a little bit about Automattic first. We're the company behind several products in the WordPress ecosystem such as wordpress.com, Jetpack, WooCommerce, as well as many other brands like Tumblr, Beeper, and many more. We are around 1,400 people and we're fully distributed which is pretty interesting for also what what I'm about to show you. We're fully distributed distributed and asynchronous which means that most of our work, our thoughts, our concepts from the past couple of decades are very well documented. I'm a product designer and I've spent over a decade building software and watching how teams build software. I've worked for I've been at Automattic for 5 years now on the Jetpack design team and in the past I worked for several companies of different sizes, different types of products, and different team organiza- configurations. So after all these years I've not only accumulated experience in designing products, I also have a lot of insight into team dynamics and organizational structures within product teams. Over the years the the designer role has morphed and evolved a lot. We we had We still have all of these different types of of roles like web designers or UX designers or interaction or product designers. We've also used many different tools from the Adobe suite to Sketch to Figma and many many others in addition to those. And AI is a new tool. It is definitely not built just for designers. It's versatile so it can be used by many other um many different roles, but the expectation is is the same for everyone. It's that it will bring a speed. And of course, this is why companies are rushing to put it to use. But no matter what role uses AI, um this velocity is going to look very different in small teams like one to three people that are building new products. Let's say a zero to one product versus large organizations that might have built entire entire product ecosystems, that have software that's anywhere between 5 and 20 years old and that have uh more than a thousand or even thousands of people. Before I dive into the experiment, I will tell you a little bit about what preceded it in terms of how we use AI at Automattic. We were encouraged to use it, to learn it, and to experiment with AI from the very beginning. At first, we had access to tools and courses. Then the AI enablement was initiated where every single employee goes through a two-week course designed specifically for their role. This is completely immersive with lectures and and focused hands-on time. Very very helpful. And over time as AI coding tools got better, everyone was encouraged to get comfortable with contributing in code. And we can thank our systems and operations team for setting up fantastic security and processes as well as documentation that's good enough that a non-engineer such as myself can spin up a working development environment. And last but not least, an incredibly helpful tool that I that I use every day for research and planning is context AC. It's an MCP server that gives AI tools access to all of the knowledge and data that we have documented over the years that I previously mentioned. So back to the experiment. About 2 months ago, we kicked off this project. The instructions were to pause the roadmap work for 30 days, pair with a partner, and ship something real. We were welcome to use AI, though it wasn't a requirement. And of course, um we couldn't all do this at once. We had to do this in in stages, and we had about a third of the company participating in the first round. That's around 500 people that started around 794 projects in these 30 days. One lucky circumstance for me was that during this month, I was also participating in this 2-week in-person AI enablement course. So AI tools played a huge role in what I was able to deliver. Um and that's why I was building not one but three different projects. And when Radico Speedman started, uh I I had some knowledge of GitHub. I would review PRs. I had played around with cloud code. But I had never until then actually built and shipped something in code. And I mean at work. Like I've done a small hobby project here and there, but that's completely that was a completely different experience. Uh I'm going to share my personal journey of how my skills and process and collaboration style shifted over the over the course of the 30 days. And this will also give us insights into how this change can be promoted and implemented at the organizational level for large companies. So this is the story of the first project I worked on and my first contributions in code. As I mentioned at the time uh Radical Speed Month was starting, I was at the in-person A&E enablement training. And over there we did an as as part of the program we did an exercise where as a group of four we had uh 2 hours to build something together. We were two designers that aren't super comfortable in code, an engineer, and a product lead. And we decided to build this board game session manager. We had a board game evening planned that night. Uh so we wanted to create an app that's that's used to create, view, and join, and manage board game event sessions. Um you can see what that looked like. This is what we built in in 2 hours. We built an app um where people can start and stop uh uh a session, uh see what games and spots are available, and even chat with each other. And on top of that we chose this 16-bit style um illustration of our actual office that uh people found especially appealing. The most interesting thing about this project isn't what we built. It was how we worked together and leveled up together. Uh at the very beginning we agreed that we all want to uh contribute, and we were very lucky that the engineer that was uh in our group was really really great at setting us up for success. So she set up the project in GitHub, helped us grap grasp some basic commands, and helped us understand how Git works. I worked with versioning in the past um for you know, in different situations, but and I thought I understood Git, but actually I didn't. I really needed someone to to tell me how it works and and what what are the best ways to to to set up a project. We were sitting together, we were testing out the app, and we were building it um together and dividing the work among us. So, we were committing code to this project. And since this wasn't this this app that we were building, it's not related to any of of our existing products, so there were no risks involved, and our focus was on learning, which was really really really great. We only used Cloud Code for this purpose, and outside of that, I think the only visual tool used was Nano Banana to to create um uh to create the office illustration. And the biggest insight, I think, for me from this project was that if you're an engineer, the impact that you have when you enable others may be far greater than the impact of doing more engineering yourself. And for any this this is a great learning for any role. It can be um the same for engineering or design or product. Keep in mind that when you're working on a team with mixed abilities, and if you're stronger in a specific skill, make sure that you're helping and enabling each other up, because now with AI, we can all do a little bit um of the work that's outside of our domain. And this was the biggest learning for me, uh that engineers will need to become enablers and teachers. Moving on to the second project I worked on, this was my main focus for the radical speed month. I paired with an engineer and um a design operations person. And our goal, our main goal, we we worked on some design system projects together in the past. And here our main goal was to surface relevant and up-to-date design system information to humans and AI tools. And this um problem space is huge. Our design system uh that we use for our WordPress ecosystem products is open source. It serves many products internally and externally and is always in flux. So, the problem space was big. Uh we saw a lot of opportunities. So, we decided to divide and each person took on a problem to tackle. And what I proposed this design system status track tracker um the solution that I proposed raised questions with the engineer around performance, around maintenance, and if we would be able to to build it in the first place. But I was kind of empowered by the previous exercise. I was allowed to experiment, so I decided to build the full idea as a proof of concept on my own. So, um the discovery portion was three people, but the design and build was just myself. And it took around 2 and 1/2 weeks to build this. And as I worked on it piece by piece, especially uh when I reached the point where I had actual live component previews working, I was really mind-blown at what I was able to achieve. I moved through the project without any um without any restrictions in mind. Um I was just trying to push the limits. And um the tracker was picking up links from the GitHub repo, from Storybook, from Figma, sorting them according to status, tagging them with the correct library names. Search worked perfectly, and I was really excited about this product, and I shared it with fellow designers. I iterated a little bit based on the feedback, but everyone was pretty excited. I built the prototype initially as a start, and then I used Figma only later in the process for some visual fine-tuning. Some things that I just couldn't explain to claw to claw code, I I wanted to deliver an image, and that worked. But the live project was was I was what I was iterating on directly. And the prototype was built within a week, and then it took another week and a half to rebuild it for some fixes, to set up a hosting, and deploy it in our internal platform as an internal tool, as well as on an external public-facing site with that that had a little bit of a curated um data and information. And delivering this this product was a defining moment for me, where I moved from a designer to a design engineer. This is of course enabled by AI, but most of all, it was enabled by the fact that I could own the entire process. We were within the radical speed month, I was allowed to experiment. I I I had the agency and made all of the necessary decisions. In large organizations, this is very hard to do, but here I could just build whatever I thought was um was needed, and I didn't have to spend a lot of time in negotiations and handover. And then that was 2 and 1/2 weeks, so I kind of had 1 week left Um a radical speed month, so I paired with a fellow designer and here you'll be able to see the incredible shift and speed and process that happened. In only 6 days, we went from zero to uh through the entire process to building an iOS chat for WooCommerce merchants that um allows them to answer shoppers in real time, reply from their phone, or even set up AI to answer the uh questions for them. And this is a fully working proof of concept that includes authentication through wordpress.com, includes a Jetpack connection. If If you use WordPress, you might know what that is. Um we also built a widget that inherits the site theming where the site visitors can actually ask the questions, as well as the the fully capable AI agent that scans the site for information and answers visitors' questions in real time, and also discerns whether it can answer a question or or not. What was important here was that the the alignment and the the ideation part was fairly easy. It was fairly easy for us two designers to align and shape the features with because we always have the users in mind. And on the process side, um what was interesting is that we started the exploration as a cloud code project folder where all of the chats and ideas were recorded into a file system. And I I noticed that that um significantly uh sped up collaboration, as well as build later. And we've uh continued I've continued this practice in my in my daily work. Um the main artifact we worked on here as well was the prototype. And that's the biggest shift for our process because normally we would start in Figma and we would work in Figma until we reach very high fidelity. But here uh, we had uh, very good plan. Then we um, built the the the prototype or the product and then we went back into Figma to just come back to it in a visual sense to build a mood board and for some UI fine-tuning. And in only 30 days, my process that has been similar for years has completely shifted. And that was true for many other people. The first project showed me how the engineer's role can be elevated from a builder to an enabler. And this is a skill that I believe will be crucial as more and more um, people in other roles start working in code. The second one moved me from a designer to a design engineer. Um, and here I'm talking about being able to push code to production in a well-established large system that requires serious onboarding and security practices. All of the company initiatives that I described together gave me the space I needed to experiment and find my own process that works within what we already have established in the company. And and the third project that I shared was just proof that we've unlocked speeds because I already had adjusted my process a little bit, but then we both leveled up together and had a shared understanding on how we can apply the tools so we could also easily meet each other. If you're in a large organization, try to implement this um even just at your team level. Uh changing processes or tools in large organizations requires shifting the human behavior behind them. So, provide your people with the access to the new tools, find your enablers and champions, create space for experimentation, and and give them agency so that they can break out of their habits and unlock the speed that AI tools can bring. Thank you.

Frontier News · by Hyperjump Technology